Business logic in controller or model?


Warning: count(): Parameter must be an array or an object that implements Countable in /home/styllloz/public_html/qa-theme/donut-theme/qa-donut-layer.php on line 274
0 like 0 dislike
11 views
There was such a dispute with colleagues, where to correctly place the application logic.


What can you suggest?
by | 11 views

7 Answers

0 like 0 dislike
As in any religious dispute, there is no one right answer. There are two approaches to this question: fat controllers and thin models, and Vice versa. In the first case, as you might guess, the business logic is in the controllers, the second — in models.
\r
Debate about which approach is more correct, being a long time and the parties can pile up a bunch of arguments both for and against any of the parties.
\r
In my view, both approaches have the right to life, but the important thing is not to disturb them in one app: select for him some one standard and him to meet.
by
0 like 0 dislike
I do not know how, but I put this:
— the application logic (aka system): routing logs, check the settings right, save and retrieve data (call the load and save any), forms processing, select a renderer (html, xml, json, redirects, ...), caching, etc. controllers (including frontcontroller)
— the logic model (aka business logic): action on data without taking into account their method of storage (to exhibit or to pay a bill, attack someone or build a building) is not strange, models
— display logic: display the system messages (if they exist, are formed in the controller) different color for even and odd table rows, display additional blocks (usually for side-bars through the other call controllers) — display (templates)
\r
It turns out that in the model focused code that knows nothing about http requests and responses, nor on the database (or other storage). Controllers just create a model object, fill them in, if necessary, data storage/query is, if required, methods models, and if the state of the model objects has changed saves them, and then passes the objects in the right display. If the application is simple (only CRUD actions), then in the model there are no methods other than getters/setters/deleterow (and sometimes they do not, data only)
by
0 like 0 dislike
"application logic" is most likely the controller. Not called "logic", though she kind of is, logic, storage, and display (MVC pattern). So my response in the controller, and the other is not logic.
by
0 like 0 dislike
Where should be the logic, clearly illustrates the classical scheme:
\rimage
by
0 like 0 dislike
In the original, something like — "MVC architecture allows to separate business logic from presentation". The model and behavior together constitute the business logic.
The model is sometimes equated to the data, it is fundamentally wrong. The model assumes the logic for data access. The state of the model is the application state.
by
0 like 0 dislike
business logic — in the domain
by
0 like 0 dislike
the application logic includes the logic of behavior of application in response to user actions (controller), And logic implementation of certain algorithms (libraries), And the logic of interaction data abstractions (such as classes in the models). And, you can ascribe the logic of the display data (view function). So either all right or clarify what you mean by application logic
by

Related questions

0 like 0 dislike
4 answers
0 like 0 dislike
3 answers
asked Mar 23, 2019 by neyronius
0 like 0 dislike
2 answers
0 like 0 dislike
2 answers
110,608 questions
257,186 answers
0 comments
28,032 users