There is a MVC pattern. The controller accepts the request and simply jerks the methods from the model. All business logic is stored in models. The models are tied to each other, i.e. Student and Courses models can know about each other, there is no complete isolation. And the call to the database comes from the model itself, i.e. the model itself knows how to go to the database to get all students with a GPA> = 3.5. For this, the model creates a method findByGpa(Double gpa){} . In the model, we describe everything that our entity can do. For example, updateStatus (), getCourse (), retakeExam (), etc. And these methods can then be reused from the controller, from each other, or from other models.

In Spring, I encountered a different approach that is not yet completely understood.

  • There is StudentDto, there are only fields in it, no methods.
  • There is StudentDao, in it there are only calls to the database in the studens table, and no more. Therefore, in this class only crud-methods.
  • There is a StudentRepository, it is the same as in dao, but you can apply to different tables. But it is not exactly.
  • There is a StudentService - here is the logic for the Student.
  • There is StudentController - it only jerks methods from Service.
  • There is a view - it receives data from the controller and renders the view.

The first question is what are the differences between dao and repository. The second question is more voluminous. If an application has a new requirement, then I would consistently call the model's methods from the controller, if there are not enough of them, I would add a new “skill” to the model, but basically I would reuse its already implemented methods. And I would get the result.

In the spring framework, if I create a new method for each new task in the Service layer, where I will implement each step of the new requirement line by line, then there is no question of reusing methods. And my Service is just a code dump that grows at the slightest extension.

How do you need to organize the code to apply all the advantages of OOP and easily scale, manage the code?

    1 answer 1

    First of all, you must honestly answer the question: do you need all these problems with the purity of the code, layers and other academic things now? If you are at the beginning of the path of mastering the craft of building software, then just learn to write code so that it works. Learn the infrastructure. Try to practice everything that is learned in the books.

    Regarding what, where, and how to dispose: Everything is very relative in this matter. As a rule, the logic should be divided into classes, observing (preferably) the principle of common responsibility. Implement business logic through services, but again, not forgetting that very principle. Personally, I have developed such an approach (not claiming to be correct):

    • The controller serves one view.
    • The controller only sends front requests to the business logic layer.
    • If one service is enough to maintain the controller, then we leave it, if there are many services, we combine them into the facade

    I can’t tell you anything clever about DAO and Repository, I have a pattern used on the ActiveRecord project, DAO are sometimes born, they are used to get objects from the database, overtake them in the DTO and give them to the query service.

    How do you need to organize the code to apply all the advantages of OOP and easily scale, manage the code?

    Uncle Bob (Robert Martin) speaks well about this in his book “Clean Code”. I advise you to read, if you care about this topic.