I have an Order model which is used on the front of the application (just in the models folder) and in the Admin module I also need this model. Do I need to create the same model only for the module? After all, the module can work separately, it is another part of the PS application asked this question earlier opinions differ

Closed due to the fact that it is necessary to reformulate the question so that it is possible to give an objectively correct answer by the participants aleksandr barakin , user192664, 0xdb , Kirill Stoianov , HamSter Oct 27 '18 at 7:25 .

The question gives rise to endless debates and discussions based not on knowledge, but on opinions. To get an answer, rephrase your question so that it can be given an unambiguously correct answer, or delete the question altogether. If the question can be reformulated according to the rules set out in the certificate , edit it .

  • If you have already asked this question before, you should not ask it again. - smellyshovel
  • not on this forum - hesoyam

1 answer 1

There are several different approaches to building architecture. For more correct academic approaches (which few people use in practice) you must keep one Order model and many dto (well, in this particular case - one for public, one for crud-admin).

However, due to the peculiarities of crud-applications - in them (due to the lack of additional business logic), the classes dto almost always coincide with the main model.

That is why the approach with anemic models is so popular and there are many supporters of this way of development.

After all, no one wants to do extra work, and creating extra layers of abstractions is the most realistic work: not only will time be spent on it during development, so even then to read the code, to support.

I somehow gave an example (just on the Order) when I had three different models in the admin panel: to create the Order entity (without the ID field), to edit the Order entity (with the ID field) and to clone an existing Order (where was ID, but not all fields, but only those that were allowed to be changed by cloning according to the rules of the project). At the same time, it was just the view model, and the model was one - Order.

Building the architecture, we proceed from the forecast “we need to lay flexibility here, since the application with a high probability will expand in this direction”. If you have one programmer on the project, and not two independent teams, one above the admin panel, one above the public, then you just waste resources on creating flexibility that will never “shoot”. And when your project moves to another programmer - be sure that he will say a lot of unkind words when for some change in Order he needs to make changes twice. First in one model, then in another. And if he forgets about the second model, he will remember more than once while searching for an error that lasts for several hours. So a good architect has a good chuiku in understanding where it is necessary to provide such solutions "for growth", and where they didn’t give up.

Want a recipe for your particular project? I will stay a little astrologer: make one model.