How does the MVC framework for Desktop applications work?

Question

I have seen many web projects like php frameworks, Asp.net, however I read in some places that MVC came before the web, it was aimed at developing desktop applications, however I did not find material on the subject.

I am not talking about Web projects, I would like to know how it works in Desktop projects, mainly folder structure, however in desktop projects, mainly C++ I have no idea how this could be implemented.

How MVC should be implemented in a C++ project and how its folder structure?

Answer 1

I cannot give a very complete answer now. But I can help with something.

This thing of organizing into folders and files is something that depends on the need. MVC does not define any of this. Each one does the MVC as well as understand. The standard exists to give a tool and not to impose a way of doing. It has several ways to get the same result by applying the standard.

I was bothered by that question and the answer also, but I do not know what to do with them so I eixei there. This is a cake recipe that does not lead anywhere, is not part of the MVC.

Often this separation is not even necessary. In others an even greater separation may be required, each component being in different projects. Few know that MVC shines brighter when it is done by different people in different projects. It’s common for people to follow patterns without wondering why they’re wearing it. MVC, like any other standard, does not solve problems that do not exist and it can create a new problem.

Look at the way you do Observer in Java and how it is done in C#. You can do it the same way in C# and now you can do it in a more convenient way in Java, but both implement the same pattern very differently.

Take a look at how the MVC using Qt (probably what else can help you).

In fact each one seems to have an insight into what this pattern actually is. Each framework implements and even interprets in a different way. Some end up changing the name a little, others use the name inappropriately, but since I am not an expert and I have never seen someone who guarantees what is and what is not MVC, I will not give my pinch (people who say they are experts and I have seen that they do not understand as much as they imagine).

Read more on article by Martin Fowler.

I don’t know how straight and organized it is but here is an example in C#. It’s not quite what you want but I think it helps.

What defines the pattern in its essence is that the data is in an object and they are dumb in relation to the rest, they only have behaviors related to the data (business rules) and not to the GUI, that is the model. The actions that the GUI must perform are received and processed by controller. It will take and manipulate the model’s data to suit the view needs. The view is that it processes the screen by receiving the data and sending commands to the controller.

In general the screen is mounted in a completely different way than what is done with web application. Of course, there are newer models that can work similarly to the web, sending a declarative code that will be rendered by some client, remote or embedded.

It is possible to do as on the web and have the model and controller and creation of the view on the server and the rendering of the view on the client (remote). This is not so simple to do, and although it may exist, I’ve never seen something ready and public to use this way (only a limitation of mine, nothing prevents and I believe it exists, I’m just saying that the common programmer will not know how to do).

But what I think is more common is to have all this in the client. The server serves only the pure data as the model in the client requests.

In some cases it is possible to have a hybrid form, perhaps with the model on the server and the controller and view on the client. There may not even be a server, eventually. Anyway, you can mount it in several ways.

An important concept that can help understand the need for MVC and see how it really applies in any type of GUI is the cohesion and coupling. The doubt probably comes from the lack of understanding of why the MVC exists.

Additional reading.

I’ve seen something about RUI and looks better than MVC. Early yet to state.

I can try to improve the answer if I have some extra details, but I think most things would be better answered in specific questions.

Answer 2

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.

Answer 3

MVC is a pattern of object-oriented development. The application has at least one View class, which takes care exclusively of drawing and maintaining the screen. The Model class takes care of the "business rules" of the application, including talking to the database if any. (Some texts speak of the Model as if it were just a passive representation of the database, but I understand that this is wrong. The name of this is ORM - Object-Relational Mapping; the Model can make use of ORM but ORM alone cannot be called Model.)

The Controller is ideally a very simple class, a thin layer between Model and View. In a cross-platform application, the Model would tend to be easily portable, while View and Controller would have large dependencies on each platform and thus be specific to each platform.

So, if you do this separation into three classes in your C++ project, you’re following the MVC pattern.

Well, that’s ideal. In the real world, we end up deviating from that. A little because platforms encourage that. When you start an Android app, there is always an Activity, which sometimes does controller, but there is no Model template, so the difficult trend to avoid is to implement the application’s "intelligence" within Activity, and then it becomes difficult to separateI was going to reuse somewhere else. The same happens on iOS, the descending class of Uiviewcontroller is already there and ends up receiving all the non-visual code as well, although the original idea was that the Controller would only help the Views in what they cannot do alone, and compatible with the Model. (At least the View classes are clearly delimited on these platforms, so promiscuity occurs more between Model and Controller.)