Thanks. I see what you mean about query and command being UOW. I'm sorry if people think I'm trying to say things bad about NHibernate, I'm not. I just am new to NH and there's a few things that I wanted help with. I really do appreciate all the time that people are taking to help me understand.
I have just one more question about Lazy Loading and Bytecode providers: I guess what I really want is for the ORM to be neither "Lazy" nor "Eager". I don't want to disable Lazy loading at the expense of having everything Eager. What I really need is an Explicit Loading option. One that means, only load relationships that I explicitly ask for via an Eager query, or just leave them null. For my purpose, that would be better than having an uninitialized Lazy collection that's ready to throw a Lazy Exception, after the original Session has been closed. Could this be achieved by using my own custom "Empty" bytecode provider as Jason Dentler originally suggested? Hugh On Aug 5, 6:59 am, Jason Meckley <[email protected]> wrote: > with NH all query (get/load/create..) and command (save, delete, > flush, ...) operations are a unit of work and all units of work > require a transaction. those are the rules of NH. > > In regards to architecture: I can see why you would think singletons > are the best (or at least a good) choice for common data access. > Singletons are stateless they work the same no matter what context > they are used in. domain objects have state. keeping stateful objects > in a stateless environment will lead to a complicated mess at best and > a failed system at worst. > > That's not to say your idea and strategies won't work, apparently they > currently do according to your statements. But they won't work with > NH. You want NH to work in a way it was never designed and you are > reaching a point where you need to make a choice. Accept the "rules" > of NH and play be them, or don't use NH. You're application won't > succeed or fail because you do or do not use NH. It just doesn't fit > with your architecture and design concepts. > > On Aug 4, 6:41 pm, Diego Mijelshon <[email protected]> wrote: > > > > > What you just described is perfectly handled by entity and query caching. > > Stop thinking your app is so special and different from anything else. It's > > not. > > > Diego > > > On Wed, Aug 4, 2010 at 19:32, Huge <[email protected]> wrote: > > > Thanks for the feedback but I really do believe that my app is > > > different! I really do need to keep Entities in memory the whole life > > > of the app. Here is the justification: > > > > There are numerous places all over the Application surface where it is > > > required to display a list of Doctors in the Medical Practice. > > > Sometimes, they appear as columns of a grid (on the Scheduler). > > > Sometimes, they appear as options in a drop-down box when the user > > > must associate something with a Provider. Users of the software > > > schedule Doctor's Appointments all day, with high frequency and > > > concurrency. It is not even conceivable to go re-select the list of > > > Doctors every time a user wants to schedule an appointment! It > > > happens way too frequently! > > > > So, Doctors are loaded into memory for the entire duration of the > > > application! They are used frequently and for widely varying > > > purposes. So are Entities that represent all the possible Users of > > > the software, because they are connected via P2P connection and can > > > come online and offline intermittently. All the Users are loaded in > > > memory the whole life of the app! I don't need to re-select them > > > whenever a user goes online or offline, I am notified instantly on the > > > P2P network connection. In practice both of these lists are small (< > > > 50 records) for all known users of the software. > > > > I don't appreciate people passing judgement on something they know > > > nothing about and saying I have bad architecture. I have put a lot of > > > time into creating an architecture that works uniquely well for our > > > situation. Just because this app doesn't always fit the usual > > > scenario of "I have to display an edit form so fire up the Unit of > > > Work", doesn't mean my situation is invalid! > > > > "An ORM is more than simply CRUD. It's cache, change tracking, > > > concurrency, unit of work, etc. transaction scripts are just CRUD > > > statements." > > > > Thank you. I need some of those features though. I don't see why I > > > have to use LazyLoading in order to get those benefits. Yes, I need > > > CRUD. But I also need Concurrency checking. And I need caching. I > > > need UOW when I pop an edit form, but I definitely don't always need > > > to use UOW, as you can see from what I wrote above. Linq2Sql can't do > > > all of this, and that's why I'm using NHibernate! > > > > Huge > > > > -- > > > 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. -- 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.
