Can I consider that my application is in MVC?

Question

Can I consider that my application is in MVC?

Navigation

#1 by (2 votes)

2

Weight, next: I'm kind of having a conceptual question.

I started to implement my application (c # - forms) thinking of following the development based on the MVC architecture. But intuitively - and I do not know if it is conceptually correct - I ended up doing the following division (I put the image of the class diagram to facilitate):

Class 'main_form': responsible for displaying data and notifying user events and actions in the system interface to the 'arvoreCont' class.

Class 'arvoreCont': Receives form requests, requests data from the database by persistence class, applies business rules and returns to view .

Persistence class: does all communication with the database for inclusion, change, deletion and query of data (with where filters).

'no', 'data', and 'transaction' classes that represent the application objects that are often used to pass data to the interface.

I do not know if I can conceptually consider using the MVC, because, from what I read, the persistence class should be along with the classes representing the objects. But for me, it makes sense to separate.

And what I initially treated as controller (class 'arvoreCont') was responsible for centralizing much of the business rule.

Can I say, based on this structure, that I use MVC? The initial intention was to use, but in the end, I do not know if I could. What do you think?

mvc

asked by anonymous 17.07.2015 / 04:47

1 answer

Error in C # when trying to add an inherited component in ToolBox Problem using the getch () function in C

score 2 · Accepted Answer

First let's define conceptually what MVC is, and then draw a parallel with its solution.

From our tag mvc :

Model-view-controller (MVC) is a model of software architecture that separates the representation of information from user interaction with it.

In this model, we have three very well defined layers:

A Model ) consists of application data, business rules, logic and functions, as well as the description of the relationship between other models.

A View view ) can be any output representation of the data, such as a table or a diagram. You can have multiple views of the same data, such as a bar chart for management and a tabular view for counters.

A Controller ) mediates the inputs and establishes how the interaction between models should be and feed the information from the views.

What you presented as a solution basically has:

An intermediary between presentation and templates, arvoreCont , which has presentation and modeling functions, but highly coupled to both;

An ancestral presentation layer, formularioPrincipal , which apparently is the basis of any screen you develop;

A layer of models, apparently managed by the intermediary.

I would not say that this architecture is MVC. I would say this is a simple 3-tier architecture with high degree of coupling and low cohesion where we have:

A presentation layer;
A business layer;
A layer of persistence and data access.

In MVC, layering makes the controller layer just enough to harmonize the flow of information between presentation and models. It does not seem to be your case.

The template layer contains most of the application's business conceptual rules, and design . It contains the specifications of each type of information, the validations made on the set of information, the restrictions, and so on. Nor does it seem to be the case. The layer you've implemented seems to be just the agent accessing a database, dependent on the middle tier.

The layer that most closely resembles MVC, in its case, is the presentation, even though it has information notification methods to the intermediate layer, which also makes it dependent on the actions of this middle layer, which does not occur in the MVC .