Funny in past conversations you determined that supporting constructor mapping would require so much rewriting/rearchitecture that it wasn't viable to look at ...
Now you ask me for a patch. hmm. Cheers, Greg On Tue, Oct 7, 2008 at 1:18 PM, Ayende Rahien <[EMAIL PROTECTED]> wrote: > 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. >> >> > > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
