locked
Anemic Domain OO Wrapper? RRS feed

  • Question

  • User461901147 posted

    I have some domain objects that have validations using EntLib5.  In order to share them across business logic and presentation layers, I can't put much behavior in them.  So they are like semi-anemic domain.

    According to wiki, "Logic cannot be implemented in a truly object-oriented way unless wrappers are used, which hide the anemic data structure.".  What exactly are wrappers?  Does this alleviate the guilt of aenmia? 

    I'm planning to have one to one mapping between domain object and domain service object.  For example, User and UserSvc.  All the user related behavior are centralized in UserSvc.  So instead User.Summerize, I can have UserSvc.Summerize.  Is that like a wrapper, or transaction script?

    BTW, in the overall design, I have EF4, Repository, Domain, Domain Svc, App Svc/WCF and Presentation.  I really can't afford using DTO except special cases like report or summary list.  I'm standing up against ASPX/Stored Proc crowd, every extra line of code could trigger a riot.

    Thanks

    Thursday, December 16, 2010 9:26 AM

All replies

  • User-1179452826 posted

    The wrapper solution isn't a solution but a hack. A wrapper class is basically a class that takes in an instance of the original class (possibly via ctor) and exposes properties and methods in addition to those available in the original class.

    It seems to me that you're attempting DDD. I say attempting coz you seem to have some DDD keywords in your post. DDD is more than those keywords. Selectively doing DDD will leave you worse off than not doing DDD at all - you'll end up with convoluted tightly coupled layers of abstraction where each layer simply delegates to the next. DTOs (boundary classes) and value objects are vital, as is understanding bounded contexts, anticorruption layers etc. If you avoid these, chances are, you'll have a system that has many complicated concepts but without the benefits DDD brings (common understanding, ability to easily change etc.). Perhaps in that scenario, simple sprocs would be an easier (even 2 layer) solution. Is your application complicated enough that a simple 2 layer solution won't work? If not, just stick to what works. If so, then investigate deeper, consult with experts, send team members to proper DDD courses, read Eric's little blue book 3 times [including the second half] (, ignore the DDD quickly book), read the GOOS book - DDD is not easy for the uninitiated. Don't focus on things that are less important than others (which are vital). 

    I know it may sound like overkill but blog posts tend to simplify DDD to a point that it looks really simple until you actually get to doing it. [And ditch EntLib - it's almost archaic.]

    Sunday, July 17, 2011 5:51 AM
  • User-389939489 posted

    > And ditch EntLib - it's almost archaic.

    It isn't, above all for 2/3-layered architectures:  of course, in such 2/3-layered architectures (which IME are enough for the majority of the web applications around), the database has nothing to do with persistence, it's rather a full-fledged system component, so even in that case there is nothing trivial actually.

    But I agree with what you have been saying about DDD, i.e. the substance of your reply to the OP.

    -LV

    Sunday, July 17, 2011 6:31 AM
  • User-1179452826 posted

    There are better OS offering to pretty much every EntLib feature. The only reason it's got ground today is coz it's 1st party.

    Sunday, July 17, 2011 6:52 AM
  • User-389939489 posted

    > There are better OS offering to pretty much every EntLib feature.

    I assume you mean open source:  which are these better products and under which respects are they better?

    > The only reason it's got ground today is coz it's 1st party.

    And that is no little thing.  But I beg to strongly disagree anyway:  the P&P team has been doing a fantastic job across the years.  --  The only reason why SOA is still not on top of the list of every architect while DDD and similar ("domain"-centred, monolithic)  approaches are is because of the blindness of the last generation of developers, driven by fake gurus, and the pure hype and speculation.  Or so I see it.

    -LV

    Sunday, July 17, 2011 7:08 AM
  • User-1179452826 posted

    Unity is arguably the worst IoC framework out there.
    Data Access Application Block: nHibernate, Simple.Data, Massive, DUCK -> something better however way you wanna do data access.
    Validation: Simpler with plain Data Annotations and FluentValidation's also brilliant.
    ...

    The EntLib solves common problems that actually arise from designs having meaningless abstractions which don't  actually add value. It solves those problems arguably well, but the fact of the matter is that simpler designs would negate a lot of those problems anyway. Instead of solving the symptoms, perhaps it's better to solve the root cause of the problem (i.e. poor design).

    The reason "SOA" is so commonplace and a nightmare is quite simple: Some people took parts of SOA, implemented what they thought it was and took that to be SOA. Hey..web services MUST be what SOA is about, right? That has transpired into pull based webs services with at most once delivery being the heart of SOA with vendors like Microsoft bringing about ADO.NET data services - yet more ways to couple the database to every single layer in your system including the UI. Then came REST - forget about resource discovery, let's just have pretty urls exposing the database structure in an even simpler manner (looking at you WCF ODATA Services). 

    SOA was never meant to be pull based web services, rather distribution of responsibilitites. Pull based at most once delivery makes that so much harder than push based at least once delivery models (MassTransit, nServiceBus). We need resilience when partner systems are down? Sure, let's have a local cache layer on top of the other 17 layers and we're golden!

    And we haven't learnt. The same thing is happening with DDD. Forget the ubiquitous language, bounded contexts, context maps and all that tree-hugging human stuff. If we have "Entities" (anaemic DTOs) as the corenerstone of our design, and a repository to fetch them from, a service to hold all the "business logic", and an ORM (very important, we must have an ORM!) - and we'll have these "aggregate" things even though the service can manipulate entities within aggregates directly coz the framework makes it easier - then voila - we're "doing" DDD. We have nHibernate fanboys and EF fanboys (err...fangirl?). Regardless of domain, the first thing we reach out for is the ORM and the database and the 15 frameworks we like using without even asking "do we need this framework or should we try to solve the underlying problems?"

    Sunday, July 17, 2011 8:06 AM
  • User-389939489 posted

    > [IoC frameworks, nHibernate, Simple.Data, Massive, DUCK, Data Annotations and FluentValidation's]

    You are still thinking domain-centric, so comparing apples with pears.

    > The EntLib solves common problems that actually arise from designs having meaningless abstractions which don't  actually add value

    You are presuming that those who use those tools do bad design:  flawed logic.

    > Hey..web services MUST be what SOA is about, right?

    Wrong, of course.

    > "Entities" (anaemic DTOs) as the corenerstone of our design, and a repository to fetch them from, a service to hold all the "business logic", and an ORM (very important, we must have an ORM!) - and we'll have these "aggregate" things even though the service can manipulate entities within aggregates directly coz the framework makes it easier - then voila - we're "doing" DDD.

    Do it if you like, that really adds nothing to this discussion, and to the points I have raised...

    -LV

    Sunday, July 17, 2011 8:47 AM
  • User-1179452826 posted

    Simple.Data, Massive, DUCK all do raw data access. Can't see anything domain centric there. Dependency injection isn't domain centric either. Fluent Validation uses fluent config to set up validation on a class. Doesn't necessarily mean DDD. And Data Annotations are part of the .NET framework. Obviously there has to be a conspiracy by the CLR team to contaminate the world with DDD, right?

    I think you're missing the sarcasm in some sections of my reply.

    EntLib is a good solution to side effects - and even then, there are better solutions (Ninject, Autofac, StructureMap etc. kick the **** out of Unity). The P&P team do a good job of 1st partying many concepts already solved by the community and more often than not, in a less than stellar way. Anybody remember the "Repository Factory"? Oh dear lord! Generic repositories are the bone of contention for many (many argue that simply having a generic repository makes it a DAL rather than a repository) - and to have an abstract factory on top - pure genius.

    Sunday, July 17, 2011 11:13 AM