Can I consider that my application is in MVC?

Asked

Viewed 296 times

3

Personally, I’m kind of having a conceptual doubt.

I started implementing my application (c# - Forms) thinking of following development based on the MVC architecture. But intuitively - and I don’t know if conceptually correct - I ended up making the following division (I put the picture of the class diagram to facilitate):

Class 'formulaPrincipal': responsible for displaying the data and notifying user events and actions in the system interface for the class 'tree Cont'.

'Cont tree 'class: takes form requests, asks database for data by class persistence, applies business rules and returns to view.

Class persistence: makes all communication with the bank for inclusion, alteration, deletion and consultation of data (with filters where).

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

Diagrama de classes

I do not know if conceptually I can consider that I used the MVC, even because, from what I read, the class persistence should be together with the classes that represent the objects. But, for me, it makes sense to separate.

And what I initially treated as controller ('tree Cont' class) has ended up responsible for the centralization of much of the business rule.

Can I say, based on this structure, what MVC use? The initial intention was to use, but in the end, I don’t know if I made it. What do you think?

mvc software-architecture

  • Do you only have one view? Or do your views extend formularioPrincipal?

  • I have several views, which represent the forms displayed to the user. I’m only displaying a "piece" so it doesn’t get too much. But the operation for the other views is similar. It interacts with a controler, which in turn interacts with persistence. They do not extend the main form.

  • I wouldn’t say it’s MVC if the controller has a business rule - it should have as many app rules as possible.

  • What you consider as 'application rules'?

  • Example of application rule: the user requests a customer list, the application knows which model and select view to send to the user - this is an application rule. So application rules are the navigation flow in the system, access permissions, log management, knowledge of what business rules to trigger to meet user requests... (Obs: when addressing someone, do it through their name with a @ in front, so the user is notified of their message).

  • @Caffé, thank you for the answers. I understood what you put... So, as I had imagined I ended up not using an architecture "standard"... :( The correct thing would be to move all the business rules to the model entities, namely, class: "Node", "Data Function" and "Transaction Function". Right? It would be 'right' within the MVC to create another hard-core class that would either center access to the bank, or should also be in a single class with business rules - in the model.? Thank you

  • MVC is a Pattern presentation design, it does not determine the responsibility of persistence (it just knows that it is not his responsibility). In any case, the more separate the responsibilities are, in all layers, the better - that is, separate the persistence of the business rules at will.

  • @Caffé, of course. Thank you!

Show 3 more comments

1 answer

2


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

Of our tag :

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

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

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

One Vision (view) can be any output of data representation, such as a table or diagram. It is possible to have multiple views of the same data, such as a bar graph for management and a tabular view for counters.

A Controller (controller) mediates the entries and establishes what the interaction between models should be like and feeding the information of the visions.

What you presented as a solution basically has:

  1. An intermediary between presentation and templates, arvoreCont, that has functions that deal with presentation and models, but highly coupled to both;
  2. A layer of ancestral presentation, formularioPrincipal, which, apparently, is the basis of any and all screen that you develop;
  3. A layer of models, apparently managed by the intermediary.

I wouldn’t say that this architecture is MVC. I would say that this is a 3 layers simple architecture with high degree of coupling and low cohesion, where we have:

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

In MVC, the stratification makes the control layer have only enough to harmonize the information flow between presentation and models. Doesn’t seem to be your case.

The model layer contains most of the application’s business conceptual rules, and by design. This is where the specifications of each type of information, the validations made about the set of information, the restrictions, and so on are. That doesn’t seem to be the case either. The layer you implemented seems to be just the agent of access to a database, dependent on the intermediate layer.

The layer that most resembles MVC, in your case, is the presentation, even if you have methods of information notification to the intermediate layer, which also makes it dependent on actions of this intermediate layer, which does not occur in MVC.

Browser other questions tagged mvc software-architecture

You are not signed in. Login or sign up in order to post.