This topic goes way beyond NHibernate, but ... :) Our domain model i believe is strictly Anemic. We even impose the requirement, that no business logic is there. Our domain classes are only data carriers, decorated with Castle.ActiveRecord attributes to convey the mapping for NH.
Now talking about interfaces, i think they have a strong argument against putting logic into POCO (that is, for making anemic domain model). The reason is what features your interfaces allow to introduce into your application (easily, and without too much work). What i am talking about is data auditing. Yesterday we were studying how Hibernate.Envers is doing auditing, and we found that for each domain class they create a second table, with all the fields in original class, plus some fields for versioning, such as Revision and Modification type (delete/insert/update). Now the real question is not how we will put the auditing data into those tables. This is easy done with interceptors. What is a question for me is how you can present that historical data for the application users! The problem is that who will write a mapping for the auditing classes, which are mostly the same as your domain model. To make long post-short, the answer is Interfaces! If you create two interfaces - IClient, and IAuditInfo, then audit class is simply a combination of these two interfaces, and our domain class can be a normal IClient implementation. If we using the approach that Fabio Maulo suggest, that is to generate implementations on the fly for the interfaces, we solve the problem of who is going to make the mapping for the auditing classes. On 16 Lie, 23:37, Tuna Toksoz <[email protected]> wrote: > I find interfaces useful in some cases. IMHO, a pattern might be an > antipattern depending on the context. > > Tuna Toksöz > Eternal sunshine of the open source mind. > > http://devlicio.us/blogs/tuna_toksozhttp://tunatoksoz.comhttp://twitter.com/tehlike > > On Thu, Jul 16, 2009 at 4:53 PM, Fabio Maulo <[email protected]> wrote: > > Yes, Darius... but every time I write a post talking about the usage of > > interfaces for entities (including only interfaces without classes or even > > only mappings without classes nor interfaces) somebody point me to Anemic > > Domain Model anti-pattern. > > When somebody point me to an anti-pattern for sure I read which is the full > > description of the anti-pattern and, over all, I pay attention to the > > possible problems... after that I do what I need (pattern or anti-pattern). > > > 2009/7/16 Darius Damalakas <[email protected]> > > >> I've found some nice documentation on this in Hibernate documentation. > > >>http://docs.jboss.org/hibernate/stable/core/reference/en/html/perform... > > >> What is interesting is that everything boils down to the fact that > >> "These problems are all due to fundamental limitations in Java's > >> single inheritance model". I guess the same applies to C#, since it > >> also supports only single inheritance. > > >> They also propose a solution - instruct that proxies must be > >> constructed for interfaces, not for implementations. They give this > >> example: > > >> <class name="CatImpl" proxy="Cat"> > >> ...... > >> <subclass name="DomesticCatImpl" proxy="DomesticCat"> > >> ..... > >> </subclass> > >> </class> > > >> On 16 Lie, 16:00, Darius Damalakas <[email protected]> wrote: > >> > Hi, > > >> > I've just upgraded to NH 2.1.x branch, and i get these errors: > > >> > WARN NHibernate.Engine.StatefulPersistenceContext.ProxyWarnLog > >> > [(null)] - Narrowing proxy to RisingStar.BLL.Model.Contact - this > >> > operation breaks == > > >> > I checked the code, and it says this: > >> > "If the existing proxy is insufficiently "narrow" (derived), > >> > instantiate a new proxy and overwrite the registration of the old one. > >> > This breaks == and occurs only for "class" proxies rather than > >> > interface" proxies" (StatefulPersistenceContext.cs: 680) > > >> > What does it mean "inssuficiently narrow ? Could someone provide an > >> > example, when a proxy is not sufficiently narrow? > > > -- > > Fabio Maulo --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
