Good day! I have a couple of questions a question related to models in asp.net mvc.

The first question. Suppose I have some kind of database. I access it through the Entity Framework. This library generates classes for my tables that I can then use. But then the question arises: what about the model? If you use these generated entities as models, then I cannot either change them (for example, add attributes for validation) because these entities are automatically generated and cannot be edited in general. 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 entities from Entity, since the database mainly stores data reflecting models.

And now the second question. In essence, these models are DTOs, that is, simply objects containing only data. And what about the logic of processing this data? Should it be in controllers? But as far as I know the controllers in Asp.net mvc should be "thin", that is, do not contain any special logic. Or should we also write additional controllers in which the logic of working with models will be concentrated? How can you tell me knowing people!

    3 answers 3

    The standard three-tier architecture implies the division of the application into three layers:

    • Presentation - UI
    • Logic - Service Level
    • Data - Database, or some other data storage method

    MVC is a pattern for organizing the UI.

    The role of the controllers in this pattern is the processing of user actions. They can be:

    • calls to business logic - methods of service-level classes (services not in the sense of WCF, but in the sense of some classes from the Service Level)
    • Data conversion to / from DTO service level in Presentation models (maybe you are looking for AutoMapper ?)
    • there is still some kind of UI logic that does not involve working with domain objects - redirects, sessions, caching, and so on.

    Those. for example order creation (classic example) looks like this:

    • The user fills out the form presses the button "create order"
    • Calls OrdersController.Create Controller collects data for calling the service - the goods in the basket (from the session), the user id, the address (coming from the client at the touch of a button).
    • The controller pulls the service level - OrderService.CreateOrder (...), giving it all collected
    • OrderService creates a context, creates a new Order, ... generally deals with business logic in its purest form.
    • OrderService returns to the top Order or OrderDTO
    • The controller selects from this Order the fields required to display the view — the order number, for example. And collects from them a model.
    • The controller returns the "OrderConfirmed" view with the model.

    It’s just that in standard MVC examples you usually do what you should never do in a live application — for example, to mention the DataContext in the controller code in general. Or pull the repository methods.

    This is done only for the sake of simplification - examples should show the difference between MV and C.

    In this case, it is believed that the separation between Presentation-Logic-Data is a matter of course.

      1. Yes, you can use meta data, create partial classes in the same namespace where you generated the Entity Framework for you.

      For example, for AspNetUser.cs:

      namespace Project.Data { [MetadataType(typeof(AspNetUserMetaData))] public partial class AspNetUser { } public class AspNetUserMetaData { public string Id { get; set; } [Display(Name = "Почта")] [Required] public string Email { get; set; } public bool EmailConfirmed { get; set; } public string PasswordHash { get; set; } public string SecurityStamp { get; set; } [Display(Name = "Телефон")] [Required] public string PhoneNumber { get; set; } public bool PhoneNumberConfirmed { get; set; } public bool TwoFactorEnabled { get; set; } public Nullable<System.DateTime> LockoutEndDateUtc { get; set; } public bool LockoutEnabled { get; set; } public int AccessFailedCount { get; set; } [Display(Name = "Логин")] [Required] public string UserName { get; set; } } }
      1. I advise you to use the pattern "Repository", a detailed description here and here . But it is better to use the " generic repository " pattern.

        Models for asp.net mvc need to create your own because this is a presentation model that does not often coincide with the model in the database 1 to 1. Good logic should be generally separate from the site, for example in WCF Services, asp.net controllers make only calls to ordering these WCF services by combining them into one transaction.

        • I understood about the models, thanks. But with my logic and rendering it in the WCF, in my opinion, it is a bit overwhelming. Firstly, it is extra time spending on communicating with wcf and secondly, why not write some classes of repository, providers, controllers or something like that so that they execute the necessary logic? - JuniorThree
        • Well, then get yourself a BusinessLogic {namespace {and create classes for working with logic} and call in asp.net controllers. - cpp_user
        • WCF is for large distributed web applications you need. - cpp_user