MVC component GUI approach

Question

I am interested in general approach for building interactive GUI using MVC3.

The idea is to build set of different components that can be integrated (plugged in) into various scenarios.

Each Component MUST have it's own model definition, controller and views. Component encapsulates not just the view but also behavior through it's controller.

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

Context in which component runs must not make any assumptions about internal details of component implementation.

On the other side the component does not make any assumptions about context in which it will be used.

Finally, the component must provide mechanism to "communicate" or "interact" with outside world. Beside internals, component must provide some kind of "external" interface (like parameters, data, functions, events whatever...) which would allow component to be integrated into execution context.

The Context (or scenario) is part which contains components. Now, the basic challenge for the context is to manage interaction between components.

Real-world Categories component example:

Component displays list of categories and allows user to perform various actions such as sorting, paging and record selection. Internally, it has it's own model which stores relevant information like current page, sort, selection, etc... Internally, it implements all required actions (for basic render, for user actions response, etc...) in it's own controller. Internally, it handles model state persistence in the view and model state restore in it's own controller.

Real-world Products component example:

Component displays list of products and allows user to perform various actions such as sorting, paging and record selection. Internally, it has it's own model which stores relevant information like current page, sort, selection, etc... Internally, it implements all required actions (for basic render, for user actions response, etc...) in it's own controller. Internally, it handles model state persistence in the view and model state restore in it's own controller.

Real-world Dashboard page (context, scenario) example:

Page displays both Categories and Products components. Products component displays all products for the currently selected category and thus must provide external interface (parameter or something) to receive selected category identifier from the context. Categories component must provide some kind of external interface so that context can act when selected category changes and provide selected category identifier for the products component.

Technically, communication approach for page updates would mostly go through AJAX but if this is possible without AJAX, it would be even better.

In the case of AJAX, I would like solution which uses server side controller(s) which decides and renders what should be updated on the client (JSON or something).

I would not like solution in the client script (client side "like" controller) which decides what actions to call and what parts of page to update - this as said in previous paragraph must be decided by controller(s) on the server.

Important: It is not necessarily for the components to work when directly called via some route.

How would you generally implement described system?

Answer 1

Each controller handles a whole user-machine pattern. That is, roughly, each controller is responsible for orchestrating the user-machine interaction for a user-case(the user-machine patterns that are the result of the analysys phase). Now if you put "standard behaviours" in controllers who will coordinate the user-machine interaction pattern? This way you will have "components" without something that coordinate their execution. In web forms you have pages that coordinates the execution of components put in them...but in Mvc thi coordination role is played by the Controllers themselves.

You can do black-boxes composed of Controllers and Views just if each of them is responsible of a whole user-machine interaction pattern. That is a "Big Components" not a small building blocks, as its is the case when you implement a CMS.

The Orchard CMS use a similar approach. However what you call components are actually pre-defined blocks that play the role of whole sections of the websites being built by the user.

Answer 2

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

However, if you wanted to go to the trouble of writing a framework on top of ASP MVC, I am sure you could achieve what you want. For example, by using Areas, you could achieve a form of encapsulation of your controllers, view models, and views.

To compose different areas for the same master view, you could write the equivalent of a front controller with its own view that took in a view model - that view model would be primed by the front controller to render actions from the different areas.

You might achieve more mileage by using a client framework such as Backbone.js on top of ASP MVC.

Answer 3

I think you need to investigate real projects and see, what approach do you need to use. Try following project and u can find many best practices:

Here u can find implementing of security measures, services, auth and many many useful.

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

It's hard to say for me how it's should be implemented. Better to code it. But using of Dependecy Injectction of Views, Controllers, Services, and Repositories are must in your case.