I've tried to google this but I want an answer once and for all.
We're having a discussion at work whether or not you can put business logic in the Model.
For example, if you want to ensure that your id sets to int in the database. can you do a intval($id) in the model class then? or if the text-input is too short. or do you "have to" do it in the controller?
Which is the correct way?
For me, things such as calculations and other stuff you don't want in a model (should be very clean) should be in the controller.
I'm sorry for possible duplicate.
Stop worrying about where to do casts to int. Start worrying about that you apparently have a very wrong understanding of MVC (as many people do, unfortunately). The model is everything. The model models your application. The model is a self-contained block that represents what your application does.
The controller is merely a way to get your model to do something. It's the glue between the outside world and "your application". The controller receives a request and based on that request decides what the model should do. The view is then asked to visualize what just happened or give the user some insight into the state of the model.
I typically think of the structure in terms of this:
- controller
- model
- services
- primitives
- storage/database
- view
The model is the largest chunk. It is broken down into primitives, which are individual objects (classes) which represent one thing in the application (user object, post object); services, which are the things you can do ("register a user", "create a post"); and storage/database, which is responsible for managing the storage/retrieval of primitives from the database. How exactly they work together and how exactly you name them depends on your app, but these are the conceptual parts you typically need to deal with.
The view is its own layer which may or may not contain templates.
As you see, that's most of the work the application needs to do, the controller is the smallest part of it. The controller mostly receives input, invokes a model service and indicates which view should be rendered in response.
To visualize why this separation makes sense: Ask yourself how you're going to use your application. Having a website on which users can do stuff is typical. But maybe you also want to have a JSON API interface for it? Or a command line client for administrative tasks? Both of these scenarios just require different input handling and different output. But "registering a user" and "creating a post" are the same actions, regardless of how they're invoked. Therefore they belong in the model, you only need a slightly different controller and view for creating a JSON API or a CLI tool. In all this, the controller really is the smallest part and must not contain business logic.
Fat models, skinny controllers.
It’s fine to do casting in your model, as then you’re only doing it in one place and not multiple places where you call the relavant setter in your controllers. If you used the setter ten times in ten different controllers, then you’d have to make sure you were casting the variable in ten different places.
