"Write your own" is never a very good answer. I know I was bringing up a touchy subject, but was hoping to avoid defensive answers. I like the performance the proxies give me, and I like the support for lazy loading, but that doesn't mean there aren't restrictions and shortcomings.
I actually did create an implementation of IInterceptor to test it out, and to fix a different potential problem I'm facing with this application, but there are quite a few methods in there that haven't been in past version. This means that 1.2 examples don't show me all the methods. I'm not sure what all the methods do, and I haven't found many examples, or any documentation. Some of the methods return an object, and in those cases, it seems that to NOT intercept, you just return null. Others, however, return bool, and it's not clear to me when I should return true and when I should return false in order to NOT intercept. Is there documentation on this somewhere, or a NH 2.0 example I can see? Thanks for the quick responses and good advice. On Oct 7, 1: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-ignora... > > >> > 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 -~----------~----~----~----~------~----~------~--~---
