For collections you have to implements ICollectionTypeFactory and inject it through NH's configuration or through Bytecode-provider
On Thu, Aug 5, 2010 at 12:53 PM, Huge <[email protected]> wrote: > 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]> > <nhusers%[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]<nhusers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > > -- 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.
