I need to know where in the MVC should I apply the business rule.
Imagine the situation: I have a school and I need to generate a calendar of classes for teachers. Each teacher has a school subject and is only available certain times. I need to generate this calendar in such a way that teachers can performing without timing conflicts.
Here are my questions:
- What part of MVC the teacher should be part of? Taking into mind that your timings data are stored externally (such as a SQL database or an XML), it should be a Model, correct?
- Now, where in the MVC the business rule that will compile the calendar should be developed? Like Controller or a Library?
- These data could be worked directly into the Model, or perhaps a specific Model to work with other Models?
Now a bit of my vision: (please, correct me if I'm wrong)
- The data from the teachers should be handled by a Model. So that I could, for example, get the timing available to him and his school subject. So, Teacher is Model.
- The compilation of the calendar could be done in a controller or library. Question: but, controllers should be related to routes, and libraries to an API?
Best Answer
Within the context of the MVC pattern, the Controller and View components are only concerned with user interactions (the Controller with reacting to requests and the View with presenting the UI). All other code, including the business logic and database access goes in the Model component.
As the Model is usually quite large, it should have an additional internal structure, but that goes beyond the scope of the MVC pattern.
Commonly, the Model is structured in layers, with a layer for the business logic, a separate layer for the database access, and possibly additional layers.
As a side note, don't make too much of the fact that libraries have API's. The API of a library is by definition the set of classes and functions that the library provides to the outside world for their use. Every library has an API, but that only becomes important when you need to provide backwards compatibility to code that was written to use older versions of the library. This is usually not needed for libraries that are used only by one application.