4

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:

  1. 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?
  2. Now, where in the MVC the business rule that will compile the calendar should be developed? Like Controller or a Library?
  3. 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)

  1. 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.
  2. 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?
David Rodrigues
  • 249
  • 1
  • 9

3 Answers3

5

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.

Bart van Ingen Schenau
  • 71,712
  • 20
  • 110
  • 179
  • Right. So, Can I create a model to work with submodels, like: `Calendar_Model` that will work above `Teacher_Model` class, that can return an array with each teacher available times without conflict, for instance? – David Rodrigues Jul 08 '14 at 17:06
  • @DavidRodrigues: Yes. Within the MVC pattern, each part will almost always consist of multiple classes. – Bart van Ingen Schenau Jul 08 '14 at 17:11
  • **All other code, including the business logic and database access goes in the Model component.** I was under the impression that the business logic **always** was part of the controller in MVC. I thought that reacting to requests is part of the **business logic** and therefore both are part of the **controller**. If this is true, I've been working with MVC wrong the last several years or our understanding of the **business logic** is different. – dphil Jul 08 '14 at 18:21
  • 1
    @dphil: It takes too much space to answer that. Can you re-ask your comment in a real question. – Bart van Ingen Schenau Jul 08 '14 at 18:34
  • 1
    @DPhil I'm from the school of thought that the controller should have *no* business logic whatsoever. Examples [here](http://programmers.stackexchange.com/questions/135724/separating-data-access-in-asp-net-mvc/135751#135751) and [here](http://programmers.stackexchange.com/questions/213317/net-mvc-project-architecture-layering/213446#213446). – Eric King Jul 08 '14 at 18:35
  • What actually is business logic? If you handle orders and put a fee over the price and calculate that fee in the controller is that business logic? – Nuri Ensing Sep 04 '18 at 07:43
  • 1
    @Bdy: The calculation of the fee would indeed be business logic. Business logic are those rules that remain in place even when a software system gets replaced by pen, paper, pocket calculator and filing cabinet. – Bart van Ingen Schenau Sep 04 '18 at 07:50
  • So its best not to include this into a controller but for example a BLL service which the model can call right?? – Nuri Ensing Sep 04 '18 at 07:55
  • 1
    @Bdy: Yes, and from the perspective of the MVC framework, that BLL service is part of the model. – Bart van Ingen Schenau Sep 04 '18 at 08:15
  • Super thanks for the fast answering I wonder why is a BLL needed when everything in a controller just works fine.. – Nuri Ensing Sep 04 '18 at 08:39
0

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.

BobDalgleish
  • 4,644
  • 5
  • 18
  • 23
0

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.

Andrew Hoffman
  • 456
  • 4
  • 14