Bow architecture. Should we allow data annotations in our domains?

Question

I am looking for an implementation of the Onion architecture in our ASP.NET MVC application. I understand that you need to separate models from domain objects, but I find that I am writing redundant code. There is redundant code because my view models and domain entities look exactly the same, except that my view models have data annotation [Serializable]. I need these serializable models because I use an ASP.NET session state in which the state server needs objects to serialize.

I personally believe that domain entities should NOT be serializable, because then they will become dependent on a particular technology. However, how can I avoid redundant code?

I must add that my maintenance methods depend on these serializable data models.

Answer 1

I would avoid annotating my domain objects with any persistence or non-domain. Thus, my domain project will not depend on another level, and I will not clutter it with things that are not related to the Domain. Although we need to bend the rules, I prefer to bend them so that they do not depend on the details of the preservation.

The goal is to keep the layers focused on their goal, because it is very easy to mix and create (over time) a large ball of dirt.

In your case, I have the feeling that you really do not have a rich domain or it is not correctly modeled. It seems you only have data structures, and your needs are CRUDY.

If you are sure that the application will not develop in order to become more complex, then it will be just manipulation of the data structure, then you can use one model for all purposes. Basically you can cut corners and use the “business” for everything. No need for abstractions and other things.

But if you think that the application will develop, or they will or will be business rules and processes, then you will need to model the behavior perceived by the business, then it is best to keep things very untied, even if at this stage they seem the same.

To make it easier, for your view model, you can define it (with a copy) and use automapper to map the business object to the view model. Another approach, it is possible that your request-service / repository / object can directly return to this view model (compare the result of the request with the view model)

Answer 2

View models can contain domain objects / models. My domain objects are partial classes and all (ultimately) are inherited from the base object that is being serialized. Because I use my domain models in some of my view models, I also use data annotations on domain models. The library of your domain model should not depend on / links to anything else (domain managed).

Answer 3

I would not call the [Serializable] data annotation as such, as it is part of the main .Net platform (mscorlib.dll). Data annotations refer to specific attributes used to validate data and other operations in ASP.Net or Entity Framework.

Should the entity be [Serializable] ? Probably not, but I don’t think that this attribute “falsifies” your domain level as other attributes that come from external, web-based or persistent libraries. This does not bind you to a specific third-party structure.

The whole problem of "redundant code" depends on IMO on the type of system you are creating. In a genuine DDD application, duplication between Domain and View Models is probably not so obvious, and the benefits of a separate presentation model are usually more expensive. Good article on this topic: Is Layering Worth The Mapping ?