Yeah, I did say that didn't I? <smacking head> We made our domain classes as dumb as possible, but what that means in reality is that the domain classes no longer have database access logic, application logic, and service tier logic embedded within them. Unfortunately, we're dealing with a really old and poorly designed legacy database with way too many external dependencies so we're somewhat limited in how closely we can get to really good designs at this stage. We're also still learning domain-driven development so we're trying to absorb as much information as quickly as we can.
So far we've used Spring.NET in several projects that include Windows Services, ASP.NET Web Services, and an ASP.NET MVC web project. It works out reasonably well with our web services since we don't actually have to create any .asmx files--Spring.NET magically forwards/redirects directly to our service tier so our web project is basically empty (e.g. mostly configuration files). The dependency injection aspect of Spring.NET works reasonably well, but could be improved. Aspects I find is either not explained/demonstrated very well, or I'm just too dense to understand it. What I don't like about Spring.NET (and NHibernate) is the excessive reliance on fragile XML. -------------------------------------------------- From: "Chad Myers" <c...@chadmyers.com> Sent: Tuesday, January 06, 2009 5:01 PM To: <fluent-nhibernate@googlegroups.com> Subject: [fluent-nhib] Re: Academic Questions > Hrm. That one has me scratching my head. What you just described (moving > logic out of the domain classes and making them anemic) is basically the > OPPOSITE of what the Domain-Driven Design and Applying Domain-Driven > Design books advocate. > > Did you perhaps phrase that incorrectly or am I missing something large > here? > > How is Spring.NET working out for you? I used to use that quite a lot but > I've found StructureMap to have a lot more functionality and be easier to > use (and no, not just because I work with Jeremy ;) ) > -c > > ________________________________ > > From: fluent-nhibernate@googlegroups.com on behalf of Lothan > Sent: Tue 1/6/2009 3:24 PM > To: fluent-nhibernate@googlegroups.com > Subject: [fluent-nhib] Re: Academic Questions > > > > > I know what you mean. I used to implement certain business logic in the > domain classes until I read Domain Driven Design, Applying Domain-Driven > Design and Patterns, and a few others. Since then we've moved our domain > classes and DAO classes into separate assemblies, made the domain classes > pretty much dumb, and access everything through services and factories as > appropriate. We're still learning as we go, so I'm hoping Fluent > NHibernate > will move us a few more inches in the right direction. > > The area we're trying to tackle now is implementing a good fluent > repository > pattern that's usable with Spring.NET for dependency injection. If anyone > has any tips, advice, or samples you're willing to share I would be > eternally grateful. > > -------------------------------------------------- > From: "Chad Myers" <c...@chadmyers.com> > Sent: Tuesday, January 06, 2009 3:22 PM > To: <fluent-nhibernate@googlegroups.com> > Subject: [fluent-nhib] Re: Academic Questions > >> No prob, a very common problem. >> >> It's strange to me why we all want to serve entities out of IoC. I used >> to do this and eventually realized (a little too late) that it was an >> anti-pattern: It led to all sorts of other problems (entities using >> services, pulling all sorts of stuff out of the IoC container, etc, etc, >> etc). >> >> The domain model should be able to be used free of everything else. It >> should stand totally by itself. As you add services and repositories and >> other stuff that acts upon the domain, THOSE things should be IoC served >> and such. >> >> But the model itself should be clean and independent. It should contain >> as >> much of the core logic of the system as possible (preferably ALL, but >> sometimes higher level coordinators or 'domain services' are necessary). >> >> The DDD book talks more about this and talks about this better than I can >> ever hope to explain it (plus I'm probably wrong on a few counts). >> >> But it should suffice to say that entities should not have "entity >> interfaces" (e.g. interfaces that match 1:1 with the entity's type >> interface) and they should definitely NOT be serviced out of the IoC >> container. This is a path of pain and heartache (trust me on this one) >> >> -c >> >> ________________________________ >> >> From: fluent-nhibernate@googlegroups.com on behalf of m4bwav >> Sent: Tue 1/6/2009 2:14 PM >> To: Fluent NHibernate >> Subject: [fluent-nhib] Re: Academic Questions >> >> >> >> >> Thanks a lot for the great answer, I hope I did not waste too much of >> your time! >> >> On Jan 6, 2:18 pm, "Chad Myers" <c...@chadmyers.com> wrote: >>> Probably the best source for this type of information is "Domain-driven >>> Design: Tackling Complexity in the Heart of >>> Software"http://domaindrivendesign.org/ >>> >>> 1.) The domain model, like any model, should be fat, rich, and not >>> abstract. Using interfaces in place of entities goes against this >>> concept. >>> 2.) Entities should *NOT* be served out of the IoC container. New >>> entities come from factories, Existing entities come from repositories. >>> 2.) Wheel() should not be self-servicing its own rim, if it requires a >>> rim, it should require it through the constructor. >>> >>> public class Rim >>> { >>> public Rim( MaterialType material, decimal diameter, string style ) >>> { >>> _material = material; >>> _diameter = diameter; >>> _style = style; >>> } >>> >>> public MaterialType Material{ get; } >>> public decimal Diameter{ get; } >>> public string StyleName{ get; } >>> >>> } >>> >>> public class PimpRim : Rim >>> { >>> public PimpRim(decimal diameter, int numberOfDiamonds) : >>> base(MaterialType.Chrome, diameter, "Spinner") >>> {} >>> >>> ... >>> >>> } >>> >>> public class Wheel >>> { >>> public Wheel( Rim rim ) >>> { >>> _rim = rim; >>> } >>> >>> } >>> >>> ________________________________ >>> >>> From: fluent-nhibernate@googlegroups.com on behalf of m4bwav >>> Sent: Tue 1/6/2009 1:31 PM >>> To: Fluent NHibernate >>> Subject: [fluent-nhib] Re: Academic Questions >>> >>> Thanks for the response, sorry if I'm wasting your time with this, >>> >>> My gut instinct is that your dead right about not using the >>> interfaces, but I still don't totally understand why. >>> Is there a design pattern or methodology that provide a deeper >>> explanation? >>> >>> I mean what if you wanted to decouple parts of a complex class, from >>> the greater hole, so you could switch them out with IoC or the factory >>> pattern or whatever? >>> >>> like this? >>> >>> public interface IRim {..} >>> public class PimpRim : IRim >>> {...} >>> public class LowCostRim: IRim >>> {...} >>> >>> public class Wheel >>> { >>> public virtual IRim Rim {get;set;} >>> public Wheel() >>> { >>> Rim = RimFactory.GetNewRim(); >>> } >>> >>> } >>> >>> public class RimFactory() >>> { >>> public IRim GetNewRim() >>> { >>> return WindsorContainer.Resolve<IRim>(); >>> } >>> >>> } >>> >>> I believe you when you say this is wrong, but if you've got the time, >>> give me a keyword so that I can get my google on and figure out why >>> >>> Cheers, >>> Mark >>> >>> On Jan 6, 12:06 pm, "Chad Myers" <c...@chadmyers.com> wrote: >>> >>> > Since this is an academic question, I'll give you an academic answer, >>> > OK? >>> >>> > Don't use interfaces for entities. >>> >>> > I'd love to hear your reason for using it, but I'll warn you that I've >>> > heard dozens and 100% of them have all been based on elements of >>> > design >>> > mistakes further up the chain or elsewhere in the system. >>> >>> > -Chad >>> >>> >>> >>> winmail.dat >>> 10KViewDownload >> >> >> >> >> > >> > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Fluent NHibernate" group. To post to this group, send email to fluent-nhibernate@googlegroups.com To unsubscribe from this group, send email to fluent-nhibernate+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fluent-nhibernate?hl=en -~----------~----~----~----~------~----~------~--~---
