What is MVC
The definition of MVC has been evolving over time. In fact it has been greatly simplified.
In fact this term was born well before the WEB applications and today it is even difficult to say exactly what it was at that time. Martin Fowler, who was there to see, wrote what he remembers in this article: GUI Architectures.
The most basic vision one has of MVC currently is the clear separation of the concepts of presentation, logic of app and objects of domain in three different types of components (Model, View and Controller), each with a specific responsibility.
Domain objects*: objects representing the domain modeling and its business rules.
A graphical representation of this separation may be as follows:
What this picture tells us is that controller knows the model and knows the view, who also knows the model, who in turn knows no one.
That is, it is paramount in the MVC that the model don’t know anyone!
Responsibility of each component in the MVC
The responsibilities of each component can be described as follows::
Model: Domain modeling - entities and other business objects.
View: Presentation of model for user interaction - forms or web pages.
Controller: Meets user requests, selects the model (for example an entity) and the view that the user will use to interact with the model.
Apart from the MVC, we can discuss a lot, as for example if the controller delivery the model in fact or whether one should always create a DTO, if the controller manipulates the model directly or uses a service facade if the controller must access the database, if the model is who is responsible for access to the bank or if neither of the two accesses the bank... But all this goes beyond the MVC, it is good not to confuse.
MVC may be associated with other Patterns design or architectural Patterns.
MVC alone cannot define the entire architecture and design of a system, especially a system that meets a complex domain.
Example of MVC implementation
The MVC seeks to find solution, for example, for the business rule codes that check the state of the controls on the form or web page (view) to make decisions.
Code example nay MVC:
class Formulario_Titulo {
void baixar_parcelas_click() {
sql = "select * from parcelas where titulo = :titulo";
if checkBox_exclui_parcelas_a_vencer.Checked {
sql += " and data_vencimento < hoje();"
}
parcelas = executa_sql(sql, textBox_titulo_id.Text);
foreach(parcela in parcelas) {
... baixa a parcela
}
}
}
The above code is attached to the view (desktop form or web page), and it is very likely that it will be replicated when this routine is needed again elsewhere and this causes problems that we all know very well.
In a system that is MVC, the code above would turn something like this:
class Formulario_Titulo {
botao_baixar_parcelas_onClick += patch();
}
class Titulo_Controller {
void patch() {
titulo.baixar_parcelas(textBox_titulo_id.Text, checkBox_exclui_titulos_a_vencer.Checked);
}
}
class Titulo {
void baixar_parcelas(String titulo_id, boolean exclui_titulos_a_vencer) {
sql = "select * from parcelas where titulo = :titulo";
if exclui_titulos_a_vencer {
sql += " and data_vencimento < hoje();"
}
parcelas = executa_sql(sql, titulo_id);
foreach(parcela in parcelas) {
... baixa a parcela
}
}
}
Then I started from a code that accumulated all the implementation in the form and divided the responsibilities into three components: Formulario_titles (view), Titulos_controller (controller, of course) and Title (model).
There are a thousand ways to implement MVC, depending on language, platform, frameworks, and other architectural and design decisions. The above example is just a pseudo-code to present a more concrete view of the concept.
Organisation of an MVC project
So far I tried to give a sense of what MVC is because it is no use trying to figure out how to organize an MVC project without having this notion.
The organization of the files and folders will also depend on the choice of language and frameworks that will be used - some frameworks have a suggested default organization that will make it easier to work with it, and you can still make your own framework or use any framework, setting its own standard.
For an idea, see the standard organization of Ruby On Rails (a framework for web applications based on Restfull and MVC):
In the examples, consider that the system provides a CRUD for an entity called Client.
nome_app/
app/
views/
clientes/
index.html.erb
new.html.erb
show.html.erb
controllers/
clientes_controller.rb
models/
cliente.rb
See also the standard organization of ASP.NET MVC C# (very similar to Rails):
Nome_App/
Views/
Cliente/
Index.cshtml
AlgumaViewEspecial.cshtml
_AlgumaParcial.cshtml
Controllers/
ClienteController.cs
Models/
ClienteModels.cs
See also as one of my projects (Java JSF), using facelets, is organized:
nome_app/
/src/main/webapp/ (Views)
cliente/
index.xhtml
new.xhtml
show.xhtml
_algumTemplate.xhtml
/src/main/java/
app/ (Controllers)
cliente/
Cliente_Controller.java
domain/
cliente/ (Model)
Cliente.java
ClienteRepo.java
Categoria.java
Note that in my Java structure I have mentioned in parentheses where each component of MVC is, as this may not be obvious in the nomenclature I use, since my nomenclature seeks to emphasize other aspects of architecture and not MVC itself (even this project using MVC). Eventually this structure will be even more complex if the complexity of the domain demands.
And there are many other folders in each project that meet other aspects and responsibilities of the system.
Completion
Once understanding the basic concept of MVC, its objective (to establish a clear separation between presentation and business responsibilities), the responsibility of each component and the relationship between them, you are free to choose the structure of your project or adapt to the structure suggested by the frameworks chosen if applicable.
And the fact that the application is Web or Desktop is not the overriding decision factor - you can base the structure of a Desktop project on any of these Web examples, the difference is that the view here is declared using Web library tags, and the Desktop app will be declared using desktop tools.
I don’t quite understand, because apparently there is no MVC standard only for C++, I think you can adapt the same folder structure, these links may help you https://code.google.com/p/sydmvc/ and https://code.google.com/p/sydmvc/source/browse/#svn/trunk
– Thiago Friedman
Yes @Thiagofriedman does not only have a pattern for C++, as I said at the beginning of the question "I have seen many Web projects", currently exists for Web and for Cocoa (from apple), I could follow the pattern of Cocoa, but I really found it a little complex and I couldn’t quite understand it. The link problem you sent to me and with the documentation, there are the files. h, but it doesn’t explain how to use folder structure (if there is any structure in this project). Thanks anyway
– Guilherme Nascimento
Did any help you more? You need something to be improved?
– Maniero
@Moustache all helped me, only I didn’t choose because I couldn’t put in "practice" and point out what I think is most appropriate to my case. But I think your argument is quite correct "MVC does not define any of this. Everyone does MVC as they see fit"
– Guilherme Nascimento