The EmptyInterceptor is exactly what I needed.  This is excellent, now
I can get all that auditing in there that I want.  Thanks!

On Oct 7, 1:27 pm, "Ayende Rahien" <[EMAIL PROTECTED]> wrote:
> You can selectively intercept by using EmptyInterceptor as a base class,
> which will also deal with the default behavior appropriately.
>
> That was not a defensive answer, by the way, that was an expression of
> intent. If you don't like it, fix it.
> The source is there, and the architecture supports it.
>
> On Tue, Oct 7, 2008 at 10:20 PM, MAMMON <[EMAIL PROTECTED]> wrote:
>
> > "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 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to