Good use of ASP.NET MVC DataAnnotations with separate assemblies

Question

Let's say that I have a domain assembly that describes a domain model, and it has a class called a product:

public class Product { public int Id { get; set; } public string Name { get; set; } } 

I have another assembly, which is a web application working with this domain model. Now I want to create a form to create new products and get some attribute validation. The easiest way to do this is to use DataAnnotations in the class. However, this leads to the fact that the domain model now contains metadata about form validation, which is not a very clear separation of problems.

There may be a MetadataType attribute for the class, but I believe this is not better. Suddenly, your domain model class has a dependency on the form validation metadata class.

Another way is to create the CreateProductForm class and add the necessary attributes there and make a mapping between the classes. However, this creates some overhead, since you need to maintain these classes separately, and changes to one may violate the other. In some scenarios this may be desirable, but in some others it may just create additional work (suppose you have an Address class, for example).

UPDATE: some people have suggested that I use AutoMapper for this, which I already know about. AutoMapper just simplifies and simplifies the comparison, in fact does not solve the problem of saving two separate classes, which will be almost the same. My preference would be to create classes of forms only if there is a definite need for this.

Is it possible to simply declare annotations in a web assembly without creating unnecessary dependencies for the domain assembly?

Answer 1

Why you do not have DataAnnotations for your domain classes. If there is something that is required, then I think it is absolutely true to mark it as required in the domain.

Other DataAnnotations, such as StringLength, Range, etc., are all absolutely right things for me to decorate your domain objects.

Implementing IValidableObject is also a perfectly acceptable thing for a domain object for IMHO.

I would not put UI elements on them, such as UIHint, or annotations describing the formatting of a property. That would be bad.

I usually avoid displaying domain classes in the user interface and using ViewModel classes with a mapping tool such as AutoMapper, etc., to map to each other. The ViewModel class contains domain class annotations with possible additional user interface annotations.

Answer 2

If you do not want to introduce a relationship between your domain model and your views, you should go along the path of the CreateProductForm class.

Depending on the size or requirements of your project, sooner or later you will have to separate your viewing model from your domain. Suppose you use the DisplayName attribute: are you going to tag domain objects?

Using a tool like AutoMapper greatly simplifies the mapping process.

Answer 3

As the state of mathieu and XHalent, you must use CreateProductForm (or CreateProductFormViewModel) together with Automapper and create attributes that automatically model the viewmodel for the action.

Thus, the entire validation form goes through your view model, and all the data validation (related to the database) goes in your domain model.

In Silverlight and WPF, it is called the MVVM pattern , and many people who make asp.net mvc recommend it.

In my current project, I also use it with Automapper. All my views have a related view model, which is a flattened version of the domain model specific to that view.

I think this was an example that I used (this is the one I still bookmarked, but this one linked in the first seems to be better.) Using the attribute means that you are returning a domain object from your action in the controller, and The automap attribute automatically maps the domain object to your view model.

Doing this should give you the separation you are looking for.