Question

So MVC is split into the

• Model
• View
• Controller layer

I thought I had a grasp on what each layer does after ready many many pages but I’m still stumped about one area, which is if something should go in the model or the controller.

I understand that Data-storage classes should go in the Controller
I understand that UI modifiers (ie pulling the right model) should go in the Controller

But what about model modifiers. So for example if we take the software shopping cart approach lets say someone clicks on the checkout button, fills out their payment details and its all approved, a postback happens to deal with this.

The postback object needs to

1. Add an entry to a database table to say allow X user download Y software
2. Send a receipt to the user
3. Log the purchase

Normally (on a non MVC) approach I’d create a class to deal with Access-generation of the software table which would call EF to store info. I would have a secondary class to send out notifications and a third class to log information.

Should I still have these classes in MVC and if so would they be classes as the controller or the model?

Answer 1

All three of the points that you have defined above form part of the model of your application; the controller should be dealing only with orchestration between the model and the UI representation (the view) presented to the user.

Adhering to SOLID principles, absolutely would agree that we are dealing with (at least) three separate components to:

1. persist the data about user x downloading software y
2. issuing receipts
3. logging

There are many ways that you might approach organising the architecture and components to do this. One way would be to have an application specific component/service that depends on these three components and uses them to carry out the operations listed. Then the controller takes a dependency on this component only.