Do MVC web frameworks favor anemic domain model in order to avoid duplication?

Question

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?

Answer 1

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

At first blush it looks like the real thing. There are objects, many named after the nouns in the domain space, and these objects are connected with the rich relationships and structure that true domain models have.

The catch comes when you look at the behavior, and you realize that there is hardly any behavior on these objects, making them little more than bags of getters and setters. Indeed often these models come with design rules that say that you are not to put any domain logic in the the domain objects.

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:

Putting behavior into the domain objects should not contradict the solid approach of using layering to separate domain logic from such things as persistence and presentation responsibilities. The logic that should be in a domain object is domain logic - validations, calculations, business rules - whatever you like to call it.

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?

Answer 2

Any web framework that covers both the front and back end has a fundamental problem. You can't use the same objects on both sides. They have to be serialised to send over the wire and you may not be using the same language on either side.

This forces you to have anaemic objects because you can send the fields, but not methods of an object over the wire.

Arguably this makes it an ADM approach.

However. You can imagine the scenario where you have a controller which instantiates OOP style models, calls their methods to perform logical operations and returns a view.

ie.

WeatherController
{
    GetWeather(string day)
    {
        var d = new Day(day)
        d.CalculateWeather();
        return new WeatherView(d.ForecastData);
    }
}

This is very OOP, Day contains the data and logic, where as an ADM approach would be

WeatherController
{
    GetWeather(Day day) //Day has no methods so we can directly bind it to the incoming data
    {
        var forecaster = new WeatherForcaster();
        var data = forecaster.CalculateWeather(d)
        return new WeatherView(data);
    }
}

Here Day is an anaemic class or struct and the logic is separated out into its own WeatherForecaster object.

Where as in the first approach I might subclass Day to produce different results, in the ADM approach I would replace the forecaster object with an alternate.

Is the automatic binding of the form data to Day, vs passing a string and instancing the model manually the key difference in these approaches? I would argue that it is not.