We are having some philosopical debates in our company about where the calls to the Business Logic should be to perform CRUD operations.
I believe that the Model should consist of your data structure and that the controller should be responsible for populating the data.
My co-worker believes that all population should be done in the model class itself, and simply called by the controller. This keeps the controller neat and clean (but, in my opinion, clutters up the model).
He also believes that any call that returns a Json object should happen in the model, not in the controller. The model would return an array to the controller, which would then return this as a Json object.
What are some different pros/cons to each and is there a right or wrong way to do this?
A controller is responsible for controlling the way that a user interacts with an MVC application. A controller contains the flow control logic for an ASP.NET MVC application. A controller determines what response to send back to a user when a user makes a browser request.
The model is responsible for managing the data of the application. It receives user input from the controller. The view renders presentation of the model in a particular format. The controller responds to the user input and performs interactions on the data model objects.
In Solution Explorer, right-click the Controllers folder and then click Add, then Controller. In the Add Scaffold dialog box, click MVC 5 Controller with views, using Entity Framework, and then click Add. Select Movie (MvcMovie. Models) for the Model class.
All business logic should be in the MODEL.
Remember, the responsibilities of each layer are thus:
One of the biggest gains is in maintenance and (later) expansion. In general:
To do the above, each layer should have no knowledge of the others in order to work properly. For example, the view should receive its data and not need to know anything about where it comes from in order to display it properly. The controller should not need to know anything about the underlying structure of the model in order to interact with it. The model should have no knowledge of how the data is to be displayed (e.g., formatting) or the workflow.
"He also believes that any call that returns a Json object should happen in the model, not in the controller. The model would return an array to the controller, which would then return this as a Json object."
NO. The Model should never format data. It also should not read formatted data. That is polluting the model and moving into the level of hell where business logic = display logic
.
JSON (coming in or going out) is just another view. So going out:
Data Store -> Model -> Controller -> View
Coming in:
View -> Controller -> Model -> Data Store
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With