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.
