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.
Best Answer
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...