MVC Component GUI Approach

I'm interested in a general approach for building an interactive GUI using MVC3.

The idea is to create a set of different components that can be integrated (connected) to different scenarios.

Each Component MUST have its own model definition, controller, and view. The component encapsulates not only the view, but also the behavior through it.

All internal implementation details, model, behavior, etc. must be inside the component, so that the component becomes independent, modular - a black box. This allows you to modify the component without breaking anything in the context in which the component is used.

The context in which the component is launched should not make any assumptions about the internal details of the implementation of the component.

On the other hand, the component makes no assumptions about the context in which it will be used.

Finally, the component should provide a mechanism for "communication" or "interaction" with the outside world. In addition to internal components, the component must provide some kind of "external" interface (for example, parameters, data, functions, events regardless of ...) that would allow the component to integrate into the execution context.

A context (or script) is the part that contains the components. Now the main problem for the context is managing the interaction between the components.

Real-world Component categories example:

The component displays a list of categories and allows the user to perform various actions, such as sorting, swapping and selecting entries. Inside, it has its own model, which stores relevant information, such as the current page, sorting, selection, etc. ... Inside, it implements all the necessary actions (for the main rendering, for the response of user actions, etc. ) It has its own controller. Inside, it handles saving the state of the model in a representation of the state of the model and model in its own controller.

Real product component example:

The component displays a list of products and allows the user to perform various actions, such as sorting, swapping and selecting entries. Inside, it has its own model, which stores relevant information, such as the current page, sorting, selection, etc. ... Inside, it implements all the necessary actions (for the main rendering, for the response of user actions, etc. ) It has its own controller. Inside, it handles saving the state of the model in a representation of the state of the model and model in its own controller.

Example page page <context script> :

The page displays the components of categories and products. The product displays all products for the currently selected category and, therefore, must provide an external interface (parameter or something else) to get the selected category identifier from the context. Component categories must provide some kind of external interface so that the context can act on the selected category changes and provide the selected category identifier for the product component.

Technically, the communication approach for updating pages will mainly go through AJAX, but if it is possible without AJAX, it will be even better.

In the case of AJAX, I would like a solution that uses a server controller (s) that solves and visualizes what needs to be updated on the client (JSON or something else).

I would like not to use the solution in the client script (on the client side “how” to the controller), which decides which actions to call and which parts of the page to update - this, as stated in the previous paragraph, should be determined by the controller (s) on the server.

Important: It is not necessary that the components work in a direct call through some route.

How do you usually implement the described system?

+4
source share
3 answers

Each controller processes the entire user machine template. That is, approximately, each controller is responsible for organizing user interaction with the machine for the user case (user machine templates that are the result of the analysis phase). Now, if you put the "standard behavior" in the controllers, which will coordinate the interaction between the user and the machine? Thus, you will have “components” without coordinating their implementation. In web forms, you have pages that coordinate the execution of the components inserted into them ... but in Mvc, the controllers themselves play the role.

You can make black boxes consisting of controllers and views only if each of them is responsible for the entire interaction template with the user and the machine. These are “large components”, not small building blocks, as this is the case when you implement a CMS.

Orchard CMS uses a similar approach . However, what you call components are actually predefined blocks that play the role of entire sections of user-created websites.

+1
source

I think you need to research real projects and see which approach you need. Try the following project and you will find many best practices:

Here you can find the implementation of security measures, services, auth and much more.

Kigg
http://www.nopcommerce.com/downloads.aspx
http://orchard.codeplex.com/

It’s hard for me to say how this should be implemented. Better to encode it. But using Dependecy Injectation for Views, Controllers, Services and Repositories should be in your case.

+4
source

It seems to me that you are trying to achieve something that may not be compatible with the web MVC philosophy (other MVC implementations might support it).

However, if you want to solve the problem of creating a framework on top of ASP MVC, I’m sure that you can achieve what you want. For example, using Areas, you can achieve a form of encapsulating your controllers, viewing models and views.

To create different areas for the same main view, you could write the equivalent of the front controller with its own view, which would take the view model - this view model would be loaded by the front controller to display actions from different areas.

You can achieve greater mileage by using a client infrastructure such as Backbone.js on top of ASP MVC.

+1
source

Source: https://habr.com/ru/post/1403221/


All Articles