Re: Finally which ORM tool?

Jon Skeet [C# MVP] wrote:
No, it's not a case of a refresh issue - it's an aliasing issue.

If you've got two objects in memory which are theoretically the same database entity - having come from the same database within the same transaction and representing the same row - then I think you've lost something in the mapping. As I say, sometimes it's not an issue, but in other cases it can be very useful to know that you'll only ever see one copy of one entity.

OK, well let me ask a fairly simple question. How would you have typically solved this problem using a solution based on pure ADO.NET? In a desktop application you might have a static class or member property somewhere to manage the "Unique" object that you're dealing with. In a multi-tier application you might have the server maintain and manage a unique copy of the object in some kind of global cache (which again would be some kind of static class/member variable that only the server managed).

However, all of that talks about a fairly obscure use of persistent objects that I have not encountered (nor even discussed until this thread) in my entire career. The fact is, ORMs like XPO and nHibernate REQUIRE you to use a session to work with persistent objects even though it's only necessary (judging from what I'm starting to understand here) in the smallest fraction of circumstances.

Surely it would be possible to overload the Save/Load methods of the persistence framework to either take a session parameter or not. Or maybe have two PersistenceController classes - one which is implicitly sessionless and another which is not.

I simply can't see that forcing everyone to use sessions (whether they need them or not) is the most elegant solution to this problem and, indeed, if you've ever done any n-tier work you'll know that it's quite the opposite for n-tier frameworks... it is a problem, not a solution.

Best Regards,

James Crosswell
Microforge.net LLC
http://www.microforge.net
.