Just a few notes...
<<Force me to make all of my methods and properties virtual, for the
use of proxies>>
Let the proxies be created by deriving from an interface instead. <class
proxy="yourInterface">
<< public virtual string FName
{
get { return _fname; }
set
{
_dateLastModified = DateTime.Now; // Problem here
_fname = value;
}
}>>
Map fields instead of properties.
I'm not saying this is the way to go, but it solves these issues.
/Roger
________________________________________
Från: nhusers@googlegroups.com [EMAIL PROTECTED] för MAMMON [EMAIL
PROTECTED]
Skickat: den 7 oktober 2008 21:55
Till: nhusers
Ämne: [nhusers] Does NH really have Persistence Ignorance with POCOs? (Proxies
question)
Lately I've been thinking about Persistence Ignorance. In the past, I
don't know if I ever procured a formal definition of the term. It
always seemed to make sense in the context it was used. My contextual
definition has historically been something like "The UI layer
shouldn't have to know or care what OR/M or other technology I'm using
to store and retrieve data", a la Separation of Concerns. I shouldn't
have any "using" directives for NHibernate namespaces in ANY of my UI
code.
With a lot of Entity Framework buzz being generated recently, due to
it's v1 release with VS2008 SP1, the term Persistence Ignorance has
been climbing the Google ranks ladder. Indeed, a Google search of the
term shows that of the top 5 results, 3 are about the Entity
Framework. Since I work in an otherwise all Microsoft shop, I am very
interested in the EF, and the recent buzz has caused me to think more
about Persistence Ignorance. Out of the box, EF doesn't have it, but
someone at MS has created a PI POCO adapter for EF v1.
http://blogs.msdn.com/jkowalski/archive/2008/09/09/persistence-ignorance-poco-adapter-for-entity-framework-v1.aspx
That article made me think of PI in a new way: not only should the UI
layer, or any other consuming layer, not have to know or care what OR/
M or other technology I'm using, but my classes should be able to be
POCOs, and I shouldn't have to make them jump through hoops in order
to be functional and "persistable". EF v1 (without the mentioned POCO
adapter) requires that classes are derived from EntityObject.
NHibernate is nice because there is no such requirement. However, I'm
not sure NHibernate is really Persistent Ignorant. It might not force
me to use dependent base classes, causing tight coupling, but it DOES:
+ Force me to make all of my methods and properties virtual, for the
use of proxies
+ Force me to override Equals() and GetHashCode(), because of proxies
+ Prevent me from putting logic in public property getters/setters,
because the proxies, upon hydrating objects, would incorrectly execute
that logic.
+ Create the "polymorphic databinding" problem with lists and
collections of objects, because of proxies.
What specifically got me on this train of thought was this problem:
public class Person
{
private string _fname;
private DateTime _dateLastModified;
public virtual string FName
{
get { return _fname; }
set
{
_dateLastModified = DateTime.Now; // Problem here
_fname = value;
}
}
}
With business rules inlined in the logic in the FName setter, won't
lazy loaded instances of Person call the setter to lazily hydrate the
instance? And wouldn't that cause the _dateLastModified value to
change, even though no real modification has been made?
So does NH really achieve Persistence Ignorance?
(PS, I'm not trying to be negative here, so let's not get the flame
throwers out just yet)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to nhusers@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
