Binding directly the form to your model helps a lot to get rid of boiler plate code, but that means that your model must have a getter/setter for each property otherwise it wouldn't be possible. Another choice would be to create another layer (DTO) only to carry the data to/from the form and then you can have a rich domain model not necessarily with getter/setter for each attribute but that means duplication of fields and validation code.
For instance, right now I'm doing a web mail application. We know that we already have the Java Mail API, a good rich domain model. However, the way it is designed makes it impossible to bind my web form to that model. I am forced to create a DTO to capture the data and then pass it to the Java Mail API. Just like this example if my domain model would be like this one, the same would happen.
From Spring MVC documentation:
Instead, it is often preferable to bind directly to your business objects.
Reusable business code, no need for duplication. Use existing business objects as command or form objects instead of mirroring them to extend a particular framework base class.
Do MVC web frameworks such as Spring MVC and Struts 2, favor anemic domain model in order to avoid duplication?
Best Answer
In Martin Fowler's article you linked, he says of the Anemic Domain Model:
However, having said that, he also says this:
This is where View Models come in.
View Models contain two things:
If the ViewModel does not contain any logic, then it is could properly be called an Anemic Model. But it is not an anemic model of the domain. While it might contain data from domain objects, the ViewModel object's sole reason for existence is to separate domain logic from presentation, just as Fowler observes.
The resulting arrangement makes it much simpler to focus on layout and user interaction in the View, without being concerned about how that interaction might pollute the domain objects and their logic, or vice versa. It is the layer of separation that Fowler describes.
See Also
The View Model Pattern
Isn't MVC Anti-OOP?