MVC : In MVC pattern, when and where is the Model created?

Question

Let's say I have an application which eventually saves and retrieves it's data to/from DB. For the sake of explanation let's imagine the application deals with students.

I have a complete API that lets me work with business logic classes and seamlessly save/load them from/to the database. So I can instantiate a "Student", then call some Save(Student) function, and it will be correctly saved into the DB (with all the connections to other entities correctly managed).

Now let's say I need to create a new window (view) in my GUI to implement some new business logic. My new view is going to be called from the main application window when the users presses some menu button.

I have created the view, the model (a class that performs the needed data manipulation and saves the results into the DB), and the controller (which acts as glue between the model and the view). It all works fine. Now my question is: when and where do I instantiate the model?

Currently I do it in the event handler of the main window, which opens my dialog, like this (pseudocode):

MainWindow::OnMyDialogRequested()
{
  Model model;
  Controller controller(model);
  GUI gui(controller);
  gui.exec();
}

The GUI is kind of stateless so it's ok if everything just dies when the user finishes working with it. When the GUI launches, it displays a splash screen, and (through the controller) asks for the model to prepare the data. When the GUI dies, it ask the model (through the controller too) to save the data back to the DB.

However, I'm concerned that instantiating the "model" and the controller this way might be a bad design decision. How do I do it properly?

Answer 1

The term Model is incredibly misleading. Most people who come to contact with the MVC architectural pattern think a model is some form of a data structure. And because MVC is mostly popular among object oriented programming, data structures are usually modeled as classes. Hence the common misconception that a model is some sort of a class. But that is not entirely correct.

Based on your exact programming approach a model might mean different things but for the most part it is usually an entire layer containing the parts which make programming fun = logic (conditions, switches, loops,...).

Let's say you are adapting domain driven design. In DDD business logic is bound to certain contexts and context are protected using aggregate roots. The problem is, aggregate roots do not appear out of thin air and should not do so. They appear as a response to a certain action, a command, mostly through factory methods - which provide them context of the creation.

But let's say you are not adapting DDD, you are not using any of the aggregate whatever buzzwords, you just have several classes acting together which - when wired up correctly - represent your business logic. So where to those classes come from?

You are very likely to encounter some sort of a service class. This service class is probably going to be represented as a singleton instance and will be stateless. It's pretty much a pure function - transforming input to output - where service dependencies are not passed as method's parameter but rather provided through some form of dependency injection (which you are doing in your example). These classes usually come from some sort of an Inversion of Control container. You register these classes and them retrieve them back. This way you extract all the ugly creational spaghetti-like code from your business logic and keeps your business logic clean.

Then there is the second type of classes. Classes which contain state. In some form these could be compared to the aggregate roots buzzword I have mentioned before. The creation of these classes should reflect some issued command or some operation but know that it is not necessary for these entities to always come out of some context as Udi (in the article I have linked to above) mentions. Although it sometimes helps to understand the domain better.

Where do these classes come from is one big unanswered question To put it generally, they usually appear where you need them. They could appear in the application layer right after validation of user's input and then be passed to your business logic layer, they could appear in the business logic layer directly. It usually boils down to your own personal needs.

So if the model you are concerned about is actually the stateless services I have mentioned, those are usually today instantiated in some sort of an IoC container while the stateful classes are instantiated by you, the programmer, when you need them.

Answer 2

You could create a factory class that creates the GUI object so you can spare the main window of the details of how to instantiate a new window. And you could invoke this factory on the event that you already use since I think is the proper place to do it.