Anemic Domain Model and the ObjectDataSource

Question

I recently realized that I'm creating my n-tier applications using the Anemic Model, Which many would argue is not the proper OO way of doing things (and that it is actually an anti pattern).

So I'm now trying to apply the Domain-Driven Design instead.

I'm used to using the objectdatasource to bind controls, such as the grid view, to my business objects. I'm confused as to how i would use the objectdatasource with the domain model. does the objectdatasource require an anemic model?

I was considering removing all objectdatasources, I find it to be a burden at times anyway (especially when it comes to debugging code and exception handling), but I'd like to know what the 'proper' way of doing things is.

Answer 1

Personally, I'm not much concerned about excluding persistence when judging an object's anemia. The business behavior of an object should be orthogonal to whether or not it's persistent and how it persists.

Behavior should be about the functionality that helps to solve the root problem. I'd concentrate on that when designing objects that are more the transfer value objects and not worry about CRUD operations.

Answer 2

I think that databinding in general rocks, although I don't have much experience with ASP.NET. It gives you a lot of benefits, so don't discard it too easiliy.

The key is to separate concerns. How you render data has nothing to do with the Domain Model itself, so a better design is to have a specialized Presentation Logic layer that maps the Domain Model to Views.

This means that you can keep your Domain Model technology-neutral so that you would be able to expose it in a lot of unforseen ways. Imagine that in the future, you will be asked to implement a WCF service, or a batch job, or a WPF/SL rich client based on the Domain Model. It should be able to handle such unforseen requirements without dragging along a lot of peculiarities tied to any particular UI technology (such as ASP.NET).

When you have ViewModels or Presentation Models for each of your Views, you can use databanding against those models. I don't know how well this works in ASP.NET, but it works like a charm in both ASP.NET MVC and WPF, and the support for that is currently being built into Silverlight 4...