How to deal with models in ASP.NET MVC?

Question

ASP.NET

Good day! I have a couple questions related to models in asp.net mvc.
Question one. Let's say I have a database. I access it through the Entity Framework. This library generates classes for my tables that I can then use. But here the question arises: what about the model? If I use these generated entities as models, then I won’t be able to change them in any way (for example, add attributes for validation), because these entities are automatically generated and generally you can’t edit them. And if you create your own models, then in 90% of cases it will turn out that these models will be wrappers over the above-mentioned entities from Entity, because the reflective model data is mainly stored in the database.
And now the second question. In fact, these models are DTOs, that is, simply objects containing only data. But what about the logic of processing this data? Should it be in controllers? But as far as I know, controllers in Asp.net mvc should be "thin", that is, they should not contain special logic. Or is it necessary to write additional controllers in which the logic of working with models will be concentrated? How to be here, tell me knowledgeable people!

Answer 1

Short answer to your question: Code First , Mappings .
Long answer: you really need to figure out what to call a model.
Personally, I am convinced that model classes that are DTOs are anemic data model anyway, and an anemic model is bad in 90% of cases. Therefore, you have two options: refuse to generate "by the picture" in favor of Code First (I recommend), or follow the path of Evgeny Kolegov - to say that the EF model is not a model, but just a graph of primitive objects with get /set-ami, and the real model is here, a wrapper above them, with real business logic, etc.
> As a matter of fact these models are DTO that is simply objects containing only the data. But what about the logic of processing this data? Should it be in controllers?
Well, it's the same question: a normal model should contain logic.
> in Asp.net mvc should be "thin", that is, do not contain special logic.
In the controller - at least, there the logic is specific not for business processes, but for the work process of the web api itself, i.e. determining what needs to be done with the business entities to satisfy the request.
> Or it is necessary to write also additional controllers in which the logic of work with models will be concentrated?
not worth it, I think in your task such an additional layer is completely redundant.
Summary: the model may well and should follow the usual rules of OOP, known for 40 years already - the data and the logic of their processing should be next to each other. Separating the business logic from the model is a kind of fetish of splitting the application into many, many layers (in fact, separating a web service with a well-defined api is already a good layer). If you feel uncomfortable that you have a model without logic, and you can’t put it there, you need to change the tools or the way they are used. The first versions of EF are the first pancake lumpy, the lack of Code First support and normal mappings was considered a serious problem. Now that is long gone.
Bonus options if you are not bound by restrictions:
1) generation of TABLES BY CLASSES, rather than mapping classes to tables: for some, this option is very suitable, plus it simplifies the management of the database schema: you always have one source of information about the data schema - this is your model. You can always use it to get the current SQL schema;
2) if you like to keep track of the object model and SQL separately (I love it that way), you can look at other ORMs - NHibernate is quite a cake for yourself. Now, of course, EF is more popular, because it’s standard and promoted, but I chose NH for my project 4 years ago because of the lack of unpleasant restrictions (for example, NH can map even on a private field, but EF didn’t know how then) and because of the presence of sane mapping mechanisms.

Answer 2

Hello!
My model was a wrapper over EF, it seems to me that this is the most acceptable option.

Answer 3

1) You can add attributes to your models and even change a little of the model, the main thing is that after the changes they correspond to the definition of the tables in the database.
2) models may contain additional logic, not necessarily pure DTOs

Answer 4

Stanislav correctly said: depending on what you call a model. Those classes that EF generates can be called models and even add logic to them, maybe even some attributes. The main thing is that all additives do not contradict the correspondences that EF has established.