No I don't. What I need is the NH dll copiede in the bin folder but not a reference to NH, nor to Castle, nor to ServiceLocator, nor to NHV etc. Etc.
-- Fabio Maulo El 29/06/2010, a las 07:48, Sal <[email protected]> escribió: > Where does the ApplicationConfiguration class live? Do you bootstrap > NH in this class as well? > > If this class exists in your UI layer, don't you still need a > reference to the NH dll for it to run? > > > On Jun 29, 12:58 am, Fabio Maulo <[email protected]> wrote: >> All projects where I'm working to have all initializations and the complete >> wire of the applications in its own specialized classes. >> Application_Start has is "why"and it is: >> >> guywire = ApplicationConfiguration.GetGuyWire(); >> guywire.Wire(); >> >> On Tue, Jun 29, 2010 at 12:44 AM, Vadim Chekan <[email protected]>wrote: >> >>> On Jun 28, 4:00 pm, Fabio Maulo <[email protected]> wrote: >>>> You can move any initialization outside your application, even better... >>> you >>>> should move it. >> >>> Global contains Application_Start, why? :))) >>> Wen saying that initialization should be moved out,we should consider >>> what type/size of application we are talking about. One size does not >>> fit all. There is no universal design pattern, all of them are applied >>> within specific conditions. >> >>> Moreover, I would argue that not application size, but initializations >>> code size matters. If I have a zoo of components, many of which >>> require initializations, I would become uncomfortable keeping all of >>> them in Global, and I would definably do what you say: move init to a >>> specialized class/function[s]. >>> Or if NH init is complicated, it deserves its own function/class. >>> NFluent which will have long initialization is a good example to be >>> moved to a separate class. >> >>> At the same time, NH initialization is very important part of >>> application. You need to glance through init routine to understand how >>> application works. Hiding it behind injector will make program more >>> difficult to understand. >>> Injectors are like pills. They help when you are sick, but if you are >>> taking them when you are healthy will only harm you. >> >>> Another reason to keep init in its own class if, for example there is >>> a possibility to have web and console/win-service application. Then >>> init routine can be reused instead of copy-pasted. >>> But again, there must be a requirement which makes you thinking you >>> will need to reuse it and there must be expectation that init is >>> complicated enough to make copy-paste looking bad. >> >>>> You can easily inject the injector. >>>> in web you can use HttpModule... why ? >>>> WCF has "behaviors" configurable via XML... why ? >>>> MVC has "ActionFilters" and "ControllerFactory".... why ? >> >>> First of all, wcf is xml configurable on a pair with attribute >>> configurable and imperative configurable. >>> If xml would be the only true way, there would be only xml >>> configuration. >> >>> Who are the bad guys pushing MS to bad design? :))) >> >>> The reason why all of them have xml configuration and use IoC pattern >>> is that those frameworks are fundamental and as result, at least some >>> projects will have a requirement: re-configuration without >>> recompilation. Not all of them, but some. >>> As being very flexible, IoC is a must in any modern fundamental >>> framework. >> >>> Now, when we are talking about a concrete web application, unlike a >>> framework, usage scenarios are known fairly well, and generally >>> speaking, we can not assume that reconfiguration without recompilation >>> is required. In fact if applied without a need, IoC can lower >>> application reliability. Compiler can not do static checks during >>> compilation so it is easy to rename a class without noticing that it >>> is referenced in well hidden injector xml. And the worst, you will not >>> notice it until appropriate function is called. Run-time errors are >>> nasty. So injectors are not so harmless to recommend them by default. >> >>>> Somebody are pushing you to do the wrong thing ? arg!! such bad guys!! >> >>> Let's stay focused on technical aspects of the question and please >>> don't make assumptions that somebody pushes me. >> >>>> With the argument "you app. can't work without NH" I saw NH calls in the >>>> code behind, if that is good for you... well... good luck!! >> >>> You are attributing me to something I haven't said nor implied. >> >>> Vadim. >> >>>> On Mon, Jun 28, 2010 at 2:48 PM, Vadim Chekan <[email protected]> >>> wrote: >>>>> I agree with Felipe, >> >>>>> 1. By moving persistence initialization into a separate http module >>>>> nothing changes: you are still having persistence calls in >>>>> presentation tier: HttpModule is part of presentation framework. May >>>>> be you imply the fact that it allows you to remove NH from referenced >>>>> assemblies? Then it does not remove dependency but creates an illusion >>>>> of dependency being removed because your app won't even start without >>>>> NH assembly. >> >>>>> 2. Often system components require initialization. In this case Global >>>>> acts not as part of presentation tier, but as application start hook, >>>>> where you put your init calls. For example in console application >>>>> it'll be Main(), in Win Service it'll be OnStart. Moving init calls >>>>> into HttpModule, which were not directly intended for initialization >>>>> make program more difficult to read. >> >>>>> 3. I can think of legitimate reasons for removing binary dependency, >>>>> for example application can use one of several persistence strategies. >>>>> Then as architect you may feel bad about linking libraries which may >>>>> be not used at all. >>>>> In scenarios when NH is the only option, linking HN assembly is a good >>>>> thing. And putting init call where it is expected to be is good too. >> >>>>> Vadim. >> >>>>> On Jun 26, 2:53 pm, nadav s <[email protected]> wrote: >>>>>> no, its a matter of having a direct reference to the DAL or event >>> worse, >>>>> a >>>>>> persistance tool that your dal uses, from the presentation layer. its >>> a >>>>>> basic 3 tier anti pattern. >> >>>>>> On Sun, Jun 27, 2010 at 12:22 AM, Felipe Oriani <[email protected]> >>>>> wrote: >>>>>>> Hi guys ... thanks for the awsers! >> >>>>>>> What is there any difference between I use an HttpModule or >>> Global.asax >>>>>>> (prerequest / postrequest) events ? one has more performace than >>> the >>>>>>> other? >> >>>>>>> On Sat, Jun 26, 2010 at 3:56 PM, John Davidson < >>> [email protected] >>>>>> wrote: >> >>>>>>>> Unfortunately there are _many_ samples on the Internet that show >>>>> almost >>>>>>>> the same initialization using the global.asax This use of an >>>>> HttpModule for >>>>>>>> this purpose needs to be described as a best practice for >>> initializing >>>>> a >>>>>>>> session in NHibernate. >> >>>>>>>> John Davidson >> >>>>>>>> Sent from my iPad >> >>>>>>>> On 2010-06-26, at 11:55, nadav s <[email protected]> wrote: >> >>>>>>>> it has nothing to do with you're question, but i don't think its >>> wise >>>>>>>> putting this code in the global asax, and therefor making you're >>>>>>>> presentation layer too much aware of you're persistancy. >>>>>>>> you can write an HttpModule that does just that and register it in >>> the >>>>> web >>>>>>>> config. >> >>>>>>>> On Sat, Jun 26, 2010 at 6:18 PM, Felipe Oriani < < >>> [email protected]> >>>>>>>> [email protected]> wrote: >> >>>>>>>>> Hi all, I'm developing an application using Asp.Net MVC. I've >>>>> developed >>>>>>>>> a session per Request... so when the browser request something >>> from >>>>> server, >>>>>>>>> the app start an session. >> >>>>>>>>> By the way, I have a page in my website that each second does a >>>>>>>>> asynchronous request by Json to take some information at cache >>> (and >>>>> the >>>>>>>>> first time, the cache is loaded from database, by repositories >>> using >>>>>>>>> Nhibernate). Everything is fine, but when I see the application >>>>> running with >>>>>>>>> NHProf, I see all "ISession" per request ... but any command is >>>>> executed >>>>>>>>> (because I load a cache). >> >>>>>>>>> I wonder, if doing so may cause a problem in the future? Or, with >>>>> many >>>>>>>>> accesses the web application may become slow ? >> >>>>>>>>> At my global.asax I do this: >> >>>>>>>>> public override void Init() >>>>>>>>> { >>>>>>>>> base.Init(); >> >>>>>>>>> PreRequestHandlerExecute += OpenNHibernateSession; >>>>>>>>> PostRequestHandlerExecute += >>> DisposeNHibernateSession; >>>>>>>>> } >> >>>>>>>>> private static void OpenNHibernateSession(object sender, >>>>>>>>> EventArgs e) >>>>>>>>> { >>>>>>>>> if (RequestHelper.IsStaticFiles()) // || >>>>>>>>> RequestHelper.IsJson()) = to avoid calls Json if necessary, but >>> i'll >>>>> need >>>>>>>>> use h in some called jsons >>>>>>>>> return; >> >>>>>>>>> ManagedWebSessionContext.Bind(HttpContext.Current, >>>>>>>>> _sessionFactory.OpenSession()); >>>>>>>>> } >> >>>>>>>>> private static void DisposeNHibernateSession(object >>> sender, >>>>>>>>> EventArgs e) >>>>>>>>> { >>>>>>>>> if (RequestHelper.IsStaticFiles()) // || >>>>>>>>> RequestHelper.IsJson()) >>>>>>>>> return; >> >>>>>>>>> var session = >>>>>>>>> ManagedWebSessionContext.Unbind(HttpContext.Current, >>>>> _sessionFactory); >>>>>>>>> if (session != null) >>>>>>>>> session.Dispose(); >> >>>>>>>>> } >> >>>>>>>>> If someone can help-me... I'll! appreciate >> >>>>>>>>> PS: Sorry for my english! >> >>>>>>>>> Cheers >> >>>>>>>>> -- >>>>>>>>> ______________________________________ >>>>>>>>> Felipe B. Oriani >>>>>>>>> <[email protected]>[email protected] | >>>>>>>>> <http://www.felipeoriani.com.br>www.felipeoriani.com.br >> >>>>>>>>> "...Trabalhe quanto puder, tornando-se útil quanto possível..." , >>> por >>>>>>>>> André Luiz >> >>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to the >>> Google >>>>> Groups >>>>>>>>> "nhusers" group. >>>>>>>>> To post to this group, send email to <[email protected]> >>>>>>>>> [email protected]. >>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>> <nhusers%[email protected]<nhusers%[email protected]> >> >> ... >> >> read more » > > -- > You received this message because you are subscribed to the Google Groups > "nhusers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
