Model-View-Controller or Model-View-Adapter

The today traditional MVC (model-view-controller) architectural pattern seems to be the winner between the candidates for web applications. The pattern indicates that the application is distributed through 3 layers: the model (data and application logic representation), the view (user interface, normally visual), and the controller (the manager that communicate both previous parties). In its raw implementation the view could have access to models directly. That explain the visual representation of the pattern as a triangle: each component is visible to others.

A most recent and strict representation (candidate  for a good dependency-inversion-principle [DIP] implementation [Martin]) is the model-view-adapter pattern. The only difference from the MVC is the controller. In the MVA pattern the controller, called adapter or mediating controller -a better name-, is the only component that mediates between views and models. In the visual representation of this pattern we use a line from the view to controller to models. The controller is dependent of the interfaces of the others. The view also needs to know about the controller. Applying DIP, the view and controllers only know about them trough their respective interfaces.

A mediating controller (a kind of Mediator, GoF pattern) is the center in a GRASP (Larman) implementation of the controller as a use-case or use-case scenario. The process is as follow: the user send a message (to execute an operation using its user-interface) to the controller (a use-case or use-case representation), then the controller coordinates the operation to satisfies the goal of the user calling domain objects, and other sub-systems objects (logging, security and persistence). Finally, the controller updates the view to show the new state of the model. That implementation use, not only the Mediatior and Controller patterns, also use the DIP principle, Indirection [GRASP], «programming to interface» [GoF] axiom, and Separation of Concerns (SoC). Because the implementation requires the use of interface variables, you must implement Factory Methods or Factories (GoF) for instantiation of concretes. A big leap to a beautiful architecture with a simple design decision.

 

Anuncios

Responder

Por favor, inicia sesión con uno de estos métodos para publicar tu comentario:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

w

Conectando a %s