wagnerblog.com

Udi has an interesting post about the notion of an Anemic Domain Model Anti-Pattern. He does point out that Datasets frequently go hand in hand with that pattern. So far so good – I am in total agreement. But somewhere along the lines Udi references Fowler, who (unless I’m misreading his point) pretty much doesn’t agree with the notion of having “dumb” objects and using services to encapsulate business rules and logic. In the Fowler post referenced, it is very clear that an object should be chock-full of intelligence. To me there is a fine line between both notions. And I have worked on successful implementations that used dumb objects with services as well as projects that followed the classic approach of encapsulating a lot of business intelligence into a given object. So I am a little puzzled that Fowler would call it an anti-pattern. There is more than one way to handle this problem and in the projects that used services and our .NET equivalent of POJO’s the service itself was useful because it represented the interface to the rest of the system that was likely to change. Thus having the code that would change segregated away from the basic structure of the object allowed for a quicker more centralized mechanism to handle change. Hope that makes sense. It worked very well at the time. To me his idea of this being an anti-pattern  works against the notion of POJOS or POCOS. In the end I wonder if this is not once again a matter of semantics.

I do definitely agree that datasets are anti-patterns when viewed in the context of that post. But lets remember that datasets answer Microsoft’s 15 year history of binding set based db results directly to UI components that have been specifically designed to deal with that. Its just more of the same history. At least they are very consistent in that approach…..  Personally I try to avoid them as much as possible. Code becomes so much more valuable to a business when it embodies the rules and logic of the business itself. Datasets cannot do that because they were designed to be generic containers.