I did? I don't recall that. Ctor mapping isn't really different than the other forms of mapping that Nhibernate has. It is different because you need to gather the data up front and then create the instance, but it is possible. Start from Loader.GetRow and move from there.
It is not trivial, but it is not a major undertaking, I would say. On Tue, Oct 7, 2008 at 11:46 PM, Greg Young <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
