Take the 2-minute tour ×

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:



Do MVC web frameworks such as Spring MVC and Struts 2, favor anemic domain model in order to avoid duplication?

share|improve this question
No, use a view model stackoverflow.com/questions/526641/… –  Daniel Little Aug 13 '13 at 2:34

1 Answer 1

In Martin Fowler's article you linked, he says of the Anemic Domain Model:



The fundamental horror of this anti-pattern is that it's so contrary to the basic idea of object-oriented design; which is to combine data and process together. What's worse, many people think that anemic objects are real objects, and thus completely miss the point of what object-oriented design is all about.

However, having said that, he also says this:


This is where View Models come in.

View Models contain two things:

  1. All of the data that is required to execute a view, and
  2. Any logic that is required to render the view, but which can be pushed back into the ViewModel, rather than cluttering the view.

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?

share|improve this answer
There's nothing wrong with a Validator<Foo>, a Calculator<Foo> or a CrookedBusinessRule<Foo>. Ultimately it's a question of reusability. Putting too much into the domain object for scenario A may make it look like a kitchen sink in scenario B. The domain object imho would first and foremost offer only methods that are absolutely necessary for keeping its state valid in the most basic scenario, and because they have to access its internal state. –  herzmeister Aug 14 '13 at 16:37
Does a True MVC pattern have a view model? I know in some projects I have done I have created a view model, but in a pure MVC implementation (if there is such a thing) would you have one? –  DmainEvent Aug 14 '13 at 20:45
@DmainEvent: It could be argued that View Models make MVC more pure by improving separation of concerns. –  Robert Harvey Aug 14 '13 at 20:50
It's interesting that concepts that are used in some technology are not used in another one, for example the View Model you talk about is not known in Java (I've never heard it before either) and in Java, frameworks advice to bind directly to the domain objects. I've been reading about this in .NET (ASP.NET MVC) and the opinion is the total opposite, they say that you shouldn't bind directly to the domain objects and create what you said "view models". Very interesting how the opinions change depending on the technology. –  Alfredo Osorio Sep 6 '13 at 14:00
The problem with view model is that you have to duplicate a lot of fields, and that's a lot of maintenance but the counter argument is that it is worth because if the model changes you don't have to update the views and also gives you more security ensuring that the view can't update fields that are not supposed to be updated in that view. –  Alfredo Osorio Sep 6 '13 at 14:11

Your Answer


