"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. " Have you heard of LLBL Gen Pro (http://www.llblgen.com/ defaultgeneric.aspx). This ORM allows you to decide between either Lazy Loading (Self Service) or Eager Loaded (Data Adapter) entity models. This fulfills your previous statement. This decision is made at design time, not run time. It may be more to your liking. The last time I used LLBL was v2. At that time it did not use POCO's for the domain entities not sure if this changed with v3 or not since it now supports multiple ORMs
On Aug 5, 4:07 pm, Jason Dentler <[email protected]> wrote: > Vadim, > > Let's review: > > User: "I have [x] problem" > Volunteer: "Are you doing [y]?" > User: "Yes. How did you know?" > Volunteer: "We see this all the time. Don't do [y]." > User: "But [y] works." > Volunteer: "No, it doesn't. You just said you had [x] problem." > User: "You're an idiot. [y] is fine. NH sucks." > Random 3rd Party: "Zomg! [volunteer] is judging [user]'s use of [y] without > knowing the facts!" > Volunteer: "Fine. I'm an idiot and NH sucks. Go use Linq2Sql and leave me > alone." > > Like Jason M said, stateful singletons are a recipe for disaster, and any > entity associated with a session is stateful. It's a fact of NH that can't > be changed. > > btw - For the data you describe, use Fabio's WellKnownInstanceType. It's in > the link Jose posted. > > Thanks, > Jason > > On Thu, Aug 5, 2010 at 12:27 PM, Vadim Chekan <[email protected]> wrote: > > On Aug 4, 2:43 pm, Jason Dentler <[email protected]> wrote: > > > IMO, keeping entities around for the lifetime of the app is bad > > architecture > > > regardless of your ORM choice. > > > Love it when you judge design even before you know what are the > > requirements ;) > > > How about all kind of dictionaries: list of countries, time zones of > > the worlds, names of world currencies? How frequently do you want to > > re-load time zones from DB? At the same time Daylight Time do change > > from time to time and you can not hardcode it. For some applications, > > let's say desktop it is perfectly valid assumption that time zone does > > not change during application life time. > > > Vadim. > > > -- > > 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.
