Aspnet core MVC - CRUD logic in the Controller, Model or Service

Asked

Viewed 323 times

-3

I came across a question, I have a very simple project here with three entities, being they Teacher, Student and Class.

I created the classes at Model. Example

namespace coreSchoolSimple.Models
{
    public class Professor
    {
        public int Id { get; set; }
        public string Nome { get; set; }
        public string Email { get; set; }
        public string Telefone { get; set; }

    }
}

For me to do CRUD, I have three options.

1-If I use VS 2017 to generate the controller with views and EF, it creates the controller already with the complete CRUD logic for me, but the logic is inside the Controller.

2- Create the controller blank, and the logic of CRUD is inside the class of each entity, example: in the Teacher class will have the methods Create, Delete, Insert and List.

3- already in this option is to create a folder called service in the project root, and make the logics within a class in this folder, and use these classes as a service for each entity, example: Professorservice.Cs will have the methods of crud. And I use it as a service.

My only question is: Is there any difference between these forms outside the question of organization? For example performance or good practices?

Root of the Project:

inserir a descrição da imagem aqui

  • There’s a difference, obviously, if I didn’t, it would be the same thing. Performance generally no, good practice does not serve nothing if it does not meet a specific motivation, and without concrete case edge to opinion. Do you have any specific doubt?

  • Yes, let’s say that I have several other methods to do (besides crud) for example calculatMediaNotas(), I must do in the respective entity class or do in another service class, I am asking this because I am starting my studies, and I want to do it in the right way.

  • 1

    And how do we know we don’t understand the whole context of your software? For some reason you think there are magic answers (I was already suspicious of believing in good practices) so you want someone to say "do it like this and everything will be beautiful", this does not exist. There is no right way without understanding the context that is working, that only you know.

  • What context did you not understand in my question? tell me so I can clarify.

  • There’s nothing to understand, because there’s no context, only you know its context.

  • 2

    I closed as P. B. Opinions by several extremely subjective elements (the example of the answer given), but would qualify as broad and unclear, given the lack of parameters and the subject very "informal conversation" (in the good sense, because it is something for a conversation and not Question + Objective Answer) - Considering that your score already allows, it would be the case to raise these doubts initially in the network chat, and as the scope focuses on one-off problems, elaborate separate questions on each of these points.

Show 1 more comment

1 answer

-1


Because then, these Visual Studio options of creating the Controller on top of a Model is good for you not having to create the Actions and Views from scratch. However, what happens is that the MVC web project is nothing more than the user interface layer than anything else. The ideal is usually to create at least other Classlibrary projects that will represent the Model and Infrastructure layer (data access). Isolating the layers by responsibility (data, model, service) makes it easier for you to modify the user interface layer technology later for example, not to mention the maintenance of the code.

The scenario below would be a customization of for your project. I removed a lot of things from the DDD, to simplify:

  1. Domain Project: contains Entities, Domain Service Interfaces, for example Iprofessorservice with Insert, Delete, Edit, Delete, and Data Access Interfaces operations with the data source (database, API, etc.), classes with business rule validations.

    • In the Domain Service classes (for example, Professorservice.Cs) you implement the interfaces with CRUD operations and use the business rule validation class. In this class Professorservice.Cs you inject the data access interface.
  2. Infrastructure Project: contains the classes that implement data access interfaces (defined in the Domain project). It has all the SQL commands and applications (or any other repository you use as an API).

In the MVC project you would use the Iprofessorservice interface (by dependency injection into the Controller) and use all CRUD methods.

In short: for very small but very small MVC projects, it may be worth using the structure that Visual Studio builds in the creation of the Controllers. Even so, I think it’s best to at least create the Domain and Infra projects (data access) separate from the MVC project. I think it’s worth "customizing" the DDD architecture to the reality of the project you’re moving.

These concepts are quite long to deal with here, but take a look at the links:

Despite being in MVC 5, this material has a lot of things about layer separation. Worth seeing: layer separation

https://www.eduardopires.net.br/2017/12/10-boas-praticas-no-desenvolvimento-com-aspnet-core/

https://dotnet.microsoft.com/learn/web/aspnet-architecture

  • Good morning Raquel, edits your answer, was with repeated texts, and wanted to thank for sharing information.

  • Good morning @Renan. Thanks for the feedback! There’s another link I’d like to share. Don’t mind the fact that it is MVC 5, because this material has plenty of things about layer separation. Worth seeing: layer separation

Browser other questions tagged

You are not signed in. Login or sign up in order to post.