Roberto M. Oliva

Se ha montado un poco de revuelo (y no es para menos) porque Martin Fowler ha publicado dos nuevos articulos revisando el patron MVC (Model View Controller) adaptándolo a los tiempos que corren (TDD, metodologías ágiles, etc):

Fowler divide el MVP en dos nuevos patrones dependiendo del nivel de responsabilidad de la vista:

Supervising controller donde la controlador y la vista tienen funcionalidades repartidas, aunque específicas.
Passive View donde la vista es “controlada” por el controlador, si me permiten la redundancia y tiene muy poca funcionalidad inherente.

Como ejemplos de ambos puntos de vista se puede consultar los siguientes enlaces, muy interesantes:

ASP.NET Supervising Controller.
Session data pattern for multi-layered apps and Model-View-Presenter ASP.NET strategies
Despues de revisar ambas aproximaciones y el siguiente documento que es una exposicion completa del patrón MVC aplicado a ASP.NET:

Model View Presenter with ASP.NET

He llegado a la conclusion que las implementaciones del patrón que he comentado en posts anteriores pueden ser mejorados aplicando los siguientes puntos:

1. Incializar los datos del controlador con los que vienen del QueryString utilizando el interfaz IContext, si procede.
2. Los errores que se puedan generar en el controlador deben de ser expuestos a traves de la vista.
3. IsPostBack depende del controlador y no de la vista. Esto se hace atendiendo a un metodo del controlador que reciba un flag equivalente al IsPostBack.
4. Hacer las redirecciones de páginas como eventos lanzados por el controlador.
5. Las acciones que realiza el controlador no debe ser parametrizadas con datos de la vista, sino con parametros pasados al metodo (ejemplo: Save(idBlog, strText)… aunque esto tengo que estudiarlo mas en detenimiento).
6. Un poco relacionado con lo anterior, el 99% de las propiedades de las vistas no se pueden leer, son siempre actualizables (get, nunca set).

Cuando he estado implementando mi aproximacion al patron MVC en el codigo que he estado desarrollando, he concluido con los siguientes problemas mas comunes (no son los unicos, pero si los mas reiterativos):
1. Recibo datos del QueryString que me definen lo que hay que mostrar. Esto es común a todas las páginas: Comprobar si se ha pasado un valor, utilizar el valor o especificar que dicho valor se requiere para el funcionamiento de la pagina. El punto 1 me permiten meter este chequeo directamente en el controlado.
2. Cada accion del controlador esta rodeada de un chequeo de excepcion. Tengo que ver la mejor manera para resolver este tema. El punto 2 puede ser una aproximación.
3. Control muy sensible del PostBack: me refiero a que hay que definir 2 metodos en el Controlador para responder al PostBack en el Presenter. Es mejor que sea el controlador el que actue según dicho PostBack.
4. La gestión de la seguridad: Según mis permisos qué puedo hacer y qué no.

Resumiendo: Cuanto más haya en el controlador, mejor (yo dixit). Por un motivo muy simple: El controlador es infinitamente mas facil de testear que la Vista.