What exactly are those controllers? We were asked to build an ATM in Java for school project, and part of our design is:
- We have accounts that stores most of informations
- We have users that can make operations for their own accounts and stores some minor informations.
(Also we have atm class to store users and make some toplevel changes)
- We have userInterface to catch inputs and use controllers.
Am I right that our accounts are models, interfaces are views and users are controllers?
Thanks a lot to address my problem,!
You say: "accounts are models". Actually no, they are not.
A domain model (also called model layer, or model) is not a single component, but a layer, composed of multiple components. It abstracts a real-life process and the needed resources. In other words, it models a business logic (represented by data and, especially, behavior).
The model layer can be part of an application, or can be shared by multiple applications.
Each of the model components has a certain role. It can be an entity (e.g. a domain object), a value object, a service, a data mapper abstraction, a repository abstraction, an abstraction of an external service (like an email or paying service), etc. By abstractions, I mean interfaces or abstract classes. The concrete implementations should not be part of the domain model, but of a different, external space vis-à-vis model, serving as infrastructure constructs.
So, your User, Account and Atm classes are just components of the model. More exactly, they are entities.
On the other hand, the controllers and the views are components of the UI layer.
The controllers (should) take the responsibility of only deferring (e.g. dispatching) the execution of the user request to the model layer. More precisely, to the service layer - which is defined as a boundary layer of the domain model and is represented by its service components. So, a certain service instance is injected into the controller as dependency. The controller passes it the current user input (data) and calls a certain method of it, in which the required user request processing steps are defined. The service instance, in conjunction with other model layer objects, performs all these steps to update the model with the user input. Having the dispatching task in mind, a controller method should therefore be slim, containing 1-3 lines of code.
The views (should) obtain (the updated) data from the domain model - by querying it (e.g. by pulling data from it) itself - and display it. Analog to the controllers, the views communicate with the model through certain service component(s).
I used the verb "should" to emphasize the fact, that there are different implementation models of the UI layer. An implementation could use the controllers and the views as described above - the original MVC design. Another implementation would use the controllers not only to update the model (through services), but also to query it (through services), in order to pass the received data to the view for displaying to the user. Or an implementation could even not use services at all, forcing the steps of processing the user request to be defined in the controllers and/or the views. And so on. So, it's up to you, how you choose to implement the UI layer.
Note that you can also have controllers and/or views named like the model components (User, Account, Atm, etc). But then you must use namespaces to differentiate between all of them - the recommended way to go. In Java, namespaces are managed by packages.
Some resources with more details (mainly web MVC related, with examples in PHP):
- How should a model be structured in MVC
- PHP - Structuring a Slim3 web application using MVC and understanding the role of the model
- MVC, controller - use cases
- GeeCON 2014: Sandro Mancuso - Crafted Design
- MVC, Delivery Mechanism and Domain Model
- Catalog of Patterns of Enterprise Application Architecture
Controllers in this context will receive user's request via interfaces and call service to perform any action, call Database layer to fetch data and populate into models, integrate model with view to create desired view and return back the combined view to the user. The User and Account will be different but related entities which have their representation in the database.
You didn't get it quite right, but don't worry -- it's actually not complicated to figure out what the parts are when you know why they exist in the first place.
Here it is:
- MODEL: MVC is an architectural pattern for separating concerns in applications with user interfaces. The model is simply the part of the application that is not concerned with the user interface. It has no code in it at all that depends on the UI, the specific operations that the UI provides. Together the view and controller define the user interface, and the model is just everything else, although when we talk about it in the context of a MVC application, we usually just refer to everything else the UI might see or affect. Sometimes this leads us to make an object in the application that is called the model, but that is not really required and often not useful.
It's important to understand that the arrows in those MVC diagrams that go in a circle show data flow. When you draw a diagram that shows dependency, the view and controller depend on the model. The model does not depend on the view.
Now that we've defined the model as "the model is not the user interface", obviously the user interface consists of the view and the controller.
We separate these, and put the user between them:
VIEW: This is the part of the user interface that presents information to the user. It determines what the user will see, hear, etc. It takes information from the model and provides information to the user.
CONTROLLER: This is the part of the user interface that gets information from the user and implements the actions that he wants to perform.
The canonical example is that the view creates the button, and the controller handles the click. The separation between the view and controller, with the user (and time) in between, is the whole purpose of MVC. They do not connect in software except via the model.
The fundamental assumption of MVC is just this: We can separate the view code from the controller code, because they run at different times. The view code runs after the model changes, before the user can act on those changes, and the controller code runs after the user decides to act.
It's also important to understand that this is never entirely accurate. MVC is an over-simplification and there are actually always connections between the controller code and the view code that don't go through the model. But we try. Most of the design work in MVC frameworks or applications is an attempt to manage and properly design the ways in which they cheat in this.
