If you want know some detail about how broke UoW http://fabiomaulo.blogspot.com/2008/12/identity-never-ending-story.html
2009/12/21 Fabio Maulo <[email protected]> > the pattern implemented by NH's session is this: > http://martinfowler.com/eaaCatalog/unitOfWork.html > > 2009/12/21 DanV <[email protected]> > > Thank you for your answers. >> I did a little research these days, I read Ayende's article and some >> other posts on the mater writen by Fabio in his blogspot like this >> one: >> http://fabiomaulo.blogspot.com/2009/01/aspect-conversation-per.html >> (for others that read this post and are interested in the subject.) >> >> There are a lot of other particularities of my project that I didn't >> motioned in my post simply because I was afraid to bloat the >> description with too many details and lose focus on the real problem. >> For example I'm using some sort of singleton entity manager that >> besides offering some specific functionality to application, it caches >> all entities that are instanced in the app. Therefore I need anyway to >> evict the entity from the manager cache when is no longer used so that >> the GC gets it, and in the same time I could evict it from the >> ISession. Or I can add an entity to a new ISession if the existing one >> crashes due to an error in the DB, which I'll have to do also if I'm >> using a Session per form, because I don't want to simply reload the >> entity from the database. >> >> Anyway, the "TIME BOMB" argument was strong enough to make me >> reconsider the solution :). >> The way I use NH is by completely encapsulating dependencies to it in >> the DAL. In the core of the app itself I only use DAL interfaces. One >> of the reasons I like NH is its non-intrusive feature. >> The architecture of the whole app has been designed to use pluggable >> modules with specific functionality and we wanted to reduce the >> dependency between modules as much as possible. >> Using one session per application would have simplified the use of >> DAL, but of course not in the detriment of performance or even worse >> to lead to problems that are detected after the app starts to be used >> by customers. For that I’ll just simply have to consider other >> approach. >> So even if I wasn’t directly answered to my question I understand that >> there is no way to flush entities selectively out of an ISession >> instance simply because conceptually ISession was not designed to be >> used like that (which is not a bad thing). >> Instead an ISession should probably not outlive a conversation and one >> should carefully design a conversation also having in mind other >> criteria like holding to a resource or memory consumption. >> >> >> >> >> On Dec 16, 5:57 pm, Fabio Maulo <[email protected]> wrote: >> > session per application is neither a pattern nor anti-pattern; it is >> only a >> > TIME BOMB. >> > >> > 2009/12/16 Jason Meckley <[email protected]> >> > >> > >> > >> > >> > >> > > the problem is how you are using the session. you need 1 session >> > > factory per application. but sessions should be opened/closed only as >> > > needed. if you continue on the path of 1 session per application then >> > > you will be working against NH not with it. >> > >> > > On Dec 16, 8:39 am, DanV <[email protected]> wrote: >> > > > Hi, >> > >> > > > I'm involved in a project where I have a very particular scenario >> that >> > > > made me initially decide to use only one session per application. >> > > > Because of that, when I try to persist an entity in the database all >> > > > other entities that changed are also persisted (by flushing the >> > > > session). >> > >> > > > These are the facts and unfortunately (for me :)) some are not under >> > > > my control: >> > > > - 2 tier MDI app , developed over WPF. >> > > > - data binding is used bind entities to controls in windows. This >> > > > means that the entity is changed as the user operates in the GUI. >> > > > Canceling is done by reloading the entity. >> > > > - lazy loading is used so the session cannot just be closed. >> > > > - and the worst, entities and app windows are not hard coded but >> > > > generated based on a model (let's say a sort of UML). This means >> that >> > > > I don't have control over what and how is presented in the interface >> > > > or how entities are related. >> > > > - I cannot open a session for each window since there can be 2 >> windows >> > > > presenting somehow the same collection and that is not possible in >> > > > NH. >> > > > - I cannot use a separate new session to save an entity also because >> > > > NH does not allow same collection associated in 2 opened sessions. >> > >> > > > Problem: >> > > > - There can be a scenario where an user can open 2 windows, make >> > > > changes in both of them but incomplete/inconsistent in one of them >> and >> > > > hit save on the other where changes are complete.. Having only one >> > > > session means that all changes will be (or at least try to be) >> written >> > > > in db during Flush and for me that will be a problem in this >> > > > particular scenario :). >> > >> > > > Question: >> > > > -Is there any way to persist ony one entity (and whatever is >> cascading >> > > > with it of course) out of all entities cached in an ISession, while >> > > > the session is opened? >> > >> > > -- >> > >> > > 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]<nhusers%[email protected]> >> <nhusers%[email protected]<nhusers%[email protected]> >> > >> > > . >> > > For more options, visit this group at >> > >http://groups.google.com/group/nhusers?hl=en. >> > >> > -- >> > Fabio Maulo- Hide quoted text - >> > >> > - Show quoted text - >> >> -- >> >> 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]<nhusers%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/nhusers?hl=en. >> >> >> > > > -- > Fabio Maulo > > -- Fabio Maulo -- 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.
