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?
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.
10
Business rules are a pervasive responsibility of the application. The view should prevent the creation of conflicting schedules by not allowing them as an option; the controller should identify interactions and prevent their being formed in conflict. The model should prevent storage of conflicting schedules.
While you have an overarching rule (“no conflicts”), the rule manifests itself in sub-rules in the various domains that affect or are affected by the rule.
The Model is your data: teachers and classes.
Your Controller, among other things, composes the model data in such a way that the View can easily digest and display it. Composing a ViewModel is a good way to do this if the logic behind displaying the data is complex.
Your View takes the data that the Controller has prepared for it, if any, and renders it.
It is popular to abstract the Model (into layers), and handle business logic behind the veil.