Return to Answer

All business logic should be in the MODEL.

Remember, the responsibilities of each layer are thus:

• Controller - bridge between the model and view. Decides where to go next.
• View - displays the data, gathers user input
• Model - business logic, interface to data store.

One of the biggest gains is in maintenance and (later) expansion. In general:

• If you need to change business logic, you should not need to modify your controller or view.
• If you change your visual display, you should not need to modify your model or controller.
• If you change your workflow, you should not need to modify your view or model.

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 is properly. The controller should not need to know anything about the underlying structure of the model in order to interact with it.

"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 not 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

All business logic should be in the MODEL.

Remember, the responsibilities of each layer are thus:

• Controller - bridge between the model and view. Decides where to go next.
• View - displays the data, gathers user input
• Model - business logic, interface to data store.

One of the biggest gains is in maintenance and (later) expansion. In general:

• If you need to change business logic, you should not need to modify your controller or view.
• If you change your visual display, you should not need to modify your model or controller.
• If you change your workflow, you should not need to modify your view or model.

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

All business logic should be in the MODEL.

Remember, the responsibilities of each layer are thus:

• Controller - bridge between the model and view. Decides where to go next.
• View - displays the data, gathers user input
• Model - business logic, interface to data store.

One of the biggest gains is in maintenance and (later) expansion. In general:

• If you need to change business logic, you should not need to modify your controller or view.
• If you change your visual display, you should not need to modify your model or controller.
• If you change your workflow, you should not need to modify your view or controller.

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 is properly. The controller should not need to know anything about the underlying structure of the model in order to interact with it.

"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 not 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

All business logic should be in the MODEL.

Remember, the responsibilities of each layer are thus:

• Controller - bridge between the model and view. Decides where to go next.
• View - displays the data, gathers user input
• Model - business logic, interface to data store.

One of the biggest gains is in maintenance and (later) expansion. In general:

• If you need to change business logic, you should not need to modify your controller or view.
• If you change your visual display, you should not need to modify your model or controller.
• If you change your workflow, you should not need to modify your view or model.

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 is properly. The controller should not need to know anything about the underlying structure of the model in order to interact with it.

"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 not 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

All business logic should be in the MODEL.

Remember, the responsibilities of each layer are thus:

• Controller - bridge between the model and view. Decides where to go next.
• View - displays the data, gathers user input
• Model - business logic, interface to data store.

One of the biggest gains is in maintenance and (later) expansion. In general:

• If you need to change business logic, you should not need to modify your controller or view.
• If you change your visual display, you should not need to modify your model or controller.
• If you change your workflow, you should not need to modify your view or controller.

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 is properly. The controller should not need to know anything about the underlying structure of the model in order to interact with it.

All business logic should be in the MODEL.

Remember, the responsibilities of each layer are thus:

• Controller - bridge between the model and view. Decides where to go next.
• View - displays the data, gathers user input
• Model - business logic, interface to data store.

One of the biggest gains is in maintenance and (later) expansion. In general:

• If you need to change business logic, you should not need to modify your controller or view.
• If you change your visual display, you should not need to modify your model or controller.
• If you change your workflow, you should not need to modify your view or controller.

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 is properly. The controller should not need to know anything about the underlying structure of the model in order to interact with it.

"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 not 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