Patch it to make it work better for your scenarios. That tends to be easier than just living with awkwardnss.
On Tue, Oct 7, 2008 at 10:13 PM, Greg Young <[EMAIL PROTECTED]> wrote: > > Let me clarify, it supports it. It's just very painful in implementation... > On 10/7/08, Ayende Rahien <[EMAIL PROTECTED]> wrote: > > Greg, > > IInterceptor.Instansiate ? > > > > On Tue, Oct 7, 2008 at 10:06 PM, Greg Young <[EMAIL PROTECTED]> > wrote: > > > >> > >> PI has always been defined as the domain not having any changes in > >> specific for it persistence mechanism. > >> > >> I believe we can give credit to Jimmy Nilsson for creating in the term > >> in ADDDP (Applying Domain Driven Design and Patterns). > >> > >> > >> > >> You could use nhibernate in a more classic repository implementation > >> (DAO layer) and not run into these issue with your proxies. > >> > >> > >> There are many other issues with nhibernate and PI ... my personal > >> largest one is the lack of support for constructor mapping which can > >> really screw with validation stories but again I can work around this > >> in the same way I can with EF, I can use DAOs and put a repository > >> over the top of them. > >> > >> Cheers, > >> > >> Greg > >> > >> On Tue, Oct 7, 2008 at 12:55 PM, MAMMON <[EMAIL PROTECTED]> wrote: > >> > > >> > 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) > >> > > > >> > > >> > >> > >> > >> -- > >> It is the mark of an educated mind to be able to entertain a thought > >> without accepting it. > >> > >> > > >> > > > > > > > > > > -- > It is the mark of an educated mind to be able to entertain a thought > without accepting it. > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
