Patrón de diseño MVPVM

El patrón de diseño Model-View-Presenter-ViewModel para WPF

Bill Kratochvil

Descargar el ejemplo de código

De todos los proyectos satisfactorios en que he participado, los mejores compartieron un resultado común: conforme la aplicación crecía, el código base se hacía más pequeño. En la superficie, esto puede parecer contradictorio, pero codificar en un entorno Agile se presta para un código base que se comprime. A medida que los requisitos cambian, se produce una refactorización y esta oportunidad de refactorización (en retrospectiva) proporciona la capacidad de volver a usar componentes existentes de manera más eficaz mientras se elimina código duplicado en el proceso.

En contraste, han habido algunos proyectos monolíticos, que algunas veces se consideraron satisfactorios, en que el código fuente creció y creció con poca oportunidad para volver a usarse. Estos proyectos se volvieron intensos en cuanto a recursos y se transformaron en un riesgo para crecimiento futuro. ¿Cuál fue la diferencia fundamental? El patrón de diseño de infraestructura que se utilizó. Los patrones que use determinarán si termina arrinconado o de cara a las oportunidades abiertas que el futuro puede ofrecer.

En este artículo, presentaré un patrón de este estilo (pasado por alto por muchos desarrolladores de Windows Presentation Foundation (WPF) debido a la popularidad del patrón Model-View-ViewModel (MVVM)) llamado patrón Model-View-Presenter-ViewModel (MVPVM). Este patrón de diseño para aplicaciones empresariales se presentó en el proyecto Prism de patrones y prácticas de Microsoft (Prism.CodePlex.com). (Nota: a este patrón no se le dio nombre, así que lo llamaré MVPVM.) La mejor descripción de Prism se obtiene a través de un extracto de la información general de su sitio web:

"Prism proporciona orientación diseñada para ayudarlo a diseñar y crear de manera más fácil aplicaciones de escritorio de Windows Presentation Foundation (WPF) enriquecidas, flexibles y fáciles de mantener, aplicaciones de Internet enriquecidas de Silverlight y aplicaciones de Windows Phone 7. Al usar patrones de diseño que incorporan importantes principios de diseño arquitectónico, como separación de asuntos y acoplamiento flexible, Prism lo ayuda a diseñar y crear aplicaciones que usan componentes acoplados de manera flexible que pueden evolucionar independientemente pero que pueden integrarse de forma sencilla y sin problemas en la aplicación total. Estos tipos de aplicaciones se conocen como aplicaciones compuestas".

La popularidad y el éxito de MVVM opaca a MVPVM, aun cuando MVPVM es la evolución de MVVM (tal como lo demostrará este artículo). MVPVM proporciona toda la potencia y la capacidad de MVVM mientras introduce la escalabilidad y la extensibilidad del patrón Model-View-Presenter (MVP). Si entiende que MVVM ha evolucionado a partir de MVP para WPF, entonces este artículo le parecerá esclarecedor.

Antes de poder apreciar la potencia y los beneficios de MVPVM en plenitud, tenemos que entender cómo evolucionó este patrón; tenemos que entender nuestra historia. El patrón Model-View-Controller (MVC) es un componente crucial para alcanzar esta comprensión, así que primero presentaré MVC, quizás de una manera en que nunca antes lo ha visto.

El patrón MVC

Observe que este debate sobre MVC es dentro del contexto de aplicaciones de escritorio; las aplicaciones web son otra historia y van más allá del alcance de este artículo.

En el documento “GUI Architectures” de Martin Fowler (bit.ly/11OH7Y), él estipula lo siguiente acerca de MVC: “Diferentes personas que leen sobre MVC en diferentes lugares sacan diferentes ideas al respecto y las describen como 'MVC'. Como si esto no causara suficiente confusión, luego se suma el efecto de malentendidos de MVC que se desarrollan a través de un sistema de teléfono descompuesto.” El documento “Whatsa Controller Anyway” en rbit.ly/7ajVeS resume la idea bastante bien al señalar: "Los científicos informáticos en general tienen la molesta tendencia de sobrecargar términos. Es decir, tienden a asignar más de un significado (a veces contradictorio) a una misma palabra". 

Smalltalk MVC se complica aún más por el hecho de que los desarrolladores carecen de una base común de experiencia con sus grandes arquitectos respecto del entorno de arquitectura. Como tal, la sobrecarga de términos y los "teléfonos descompuestos" resultan todavía más enrevesados por el hecho de que la mayoría de nosotros ni siquiera sabe lo que es un Controller, porque nunca hemos tenido que usar uno; el sistema operativo siempre ha administrados sus funciones por nosotros. Con un par de hechos para proporcionar la base común de experiencia de la cual carecemos, descubrirá que MVC en realidad es fácil de entender y que la "C" en MVC no tiene nada en común con la "P" en MVP.

Controller sí tiene un origen concreto (que vale la pena comprender, pero que no necesariamente coincide con los enfoques modernos respecto de MVC en el contexto de tecnologías actuales). El padre fundador de MVC, Trygve Reenskaug, escribió sobre eso en 1979 en su documento sobre “Models-Views-Controllers” (bit.ly/2cdqiu). Este documento comienza por arrojar un poco de luz sobre el propósito de Controller. Reenskaug escribió:

"Un controlador es el vínculo entre un usuario y el sistema. Proporciona al usuario información al organizar que vistas pertinentes se presenten en lugares adecuados de la pantalla. Proporciona medios para la información del usuario al presentarle menús u otros medios para dar comandos y datos. El controlador recibe tal información del usuario, la traduce en mensajes adecuados y pasa estos mensajes a una o más vistas.

Un controlador nunca debe complementar las vistas, nunca debe, por ejemplo, conectar las vistas con nodos al dibujar flechas entre ellos.

A la inversa, una vista nunca debe saber sobre la información del usuario, como operaciones del mouse y pulsaciones de teclas. Siempre debe ser posible escribir un método en un controlador que envía mensajes a vistas, el cual reproduce exactamente cualquier secuencia de comandos del usuario".

Este concepto se muestra en la Figura 1.

Un "mensaje", en el contexto de programación orientada a objetos (OOP) de MVC, es un medio de ejecutar métodos. Se describían como "mensajes" porque por entonces las llamadas virtuales eran un concepto nuevo y era una manera de distinguirlas de llamadas de función estáticas. En el capítulo 1.2 del libro “Smalltalk, an Introduction to Application Development Using VisualWorks” (Prentice Hall, 1995), de Trevor Hopkins y Bernard Horan, los autores señalan "... si el objeto que recibe entiende el mensaje que se ha enviado, entonces se realizará una de sus operaciones (o métodos) internos. Esto, a su vez, puede generar que tenga lugar cierta informática (al actuar en una o más de las variables internas del objeto)". (Nota: este concepto de OOP de "envío de mensajes" está disponible en Prism a través de EventAggregator.)

En el libro se describen bastante bien las responsabilidades de Smalltalk MVC en el Capítulo 29, “Introduction to Models, Views and Controllers”, al enseñarnos que los Controllers derivan de la clase Controller. Se señala, "Las instancias de esta clase tienen una referencia a un sensor que representa el mouse y el teclado, para que pueda procesar información". Y continúa al decirnos que las dos acciones distintivas iniciadas a partir de un Controller son comunicaciones con Model (ver Figura 1) y comunicaciones con View sin afectar el modelo.

Figura 1 Controller recibe información y envía mensaje (método a ejecutar); Views no pueden captar la información del usuario

En Smalltalk MVC, "cada" View tendrá un Controller y solo un Controller en un momento determinado puede estar activo. En el Smalltalk MVC original, la UI se sondeaba; la clase de nivel superior ControlManager pregunta a cada uno de los Controllers de View activa si quiere el control. Solo la View que contiene el cursor puede aceptar el control. Si una View es de solo lectura, hay una clase NoController disponible que está diseñada para rechazar el control. Una View con subvistas tiene la responsabilidad de sondear los Controllers de sus subvistas. Una vez que un Controller ha aceptado el control, consultará los resultados del teclado o mouse y enviará mensajes a View o Model según corresponda, como la movida del mouse, el clic en un botón, etcétera. En términos de MVVM, esto sería comparable a suscribirse a los eventos de un control en el código subyacente de View o a través de un comando ViewModel. Cuando un usuario interactúe con el control, se llamará al método aplicable.

En este punto, puede comenzar a tener una idea detrás del propósito de Controller dentro del contexto de MVC y un entorno que no administra eventos de manera automática para usted. A diferencia de los desarrolladores de MVC, los desarrolladores de WPF no tienen que consultar los búferes de teclados ni elevar eventos. Simplemente se suscribe a ellos y el método aplicable los recibe "automáticamente" a través del Patrón de eventos de Microsoft. Sabiendo esto, lo siguiente quizás tenga otro significado, menos confuso.

En el artículo de Steve Burbeck “Applications Programming in Smalltalk-80: How to Use Model-View-Controller (MVC)” (bit.ly/3ZfFCX), él señala lo siguiente:

"El controlador interpreta las entradas del usuario del mouse y el teclado, y ordena al modelo o a la vista que cambie según corresponda. Por último, el modelo administra el comportamiento y los datos del dominio de la aplicación, responde a las solicitudes de información acerca de su estado (generalmente de la vista) y responde a instrucciones para cambiar el estado (generalmente del controlador)".

Vea la Figura 2 para obtener una ilustración de este concepto.

Figura 2 Smalltalk Model-View-Controller

Una última acotación para aclarar lo que podría ser un tema complicado de este documento, “Twisting the Triad, the Evolution of the Dolphin Smalltalk MVP Application Framework,” de Andy Bower y Blair McGlashan en bit.ly/o8tDTQ (descarga en PDF). Este es uno de los documentos más integrales que he leído sobre el tema. Los autores observan lo siguiente acerca de Controller: "Las vistas, por supuesto, son responsables de mostrar los datos de dominio mientras que los controladores administran los gestos sin procesar de usuario que en definitiva realizarán las acciones sobre estos datos".  

Saco a colación este último punto para tener la oportunidad de proporcionar otra definición. Para comprender por completo el artículo (y otros sobre MVC), se debe entender lo que significan "gestos" (vea la Figura 1). En mi investigación, me topé con el artículo “An Introduction to GUI Programming with UIL and Motif” (bit.ly/pkzmgc), en el cual se señala lo siguiente:

"La esencia de estos pasos es que un programa Motif no hace nada hasta que el usuario solicita alguna acción. Las acciones se solicitan al seleccionar un elemento de menú, hacer clic en un botón u otra ventana o al presionar una tecla. Todo esto, en conjunto, son los gestos del usuario. Cada gesto activará una función de aplicación para llevar a cabo algunas tareas".

Andy Bower, coautor de “Twisting the Triad,” compartió sus pensamientos sobre los "gestos" conmigo:

"Mi opinión sobre los 'gestos' es que son una transformación de uno o más eventos de usuario en algo más significativo.

Por ejemplo, un TextController podría absorber eventos de tecla hacia arriba y tecla hacia abajo y convertirlos en gestos individuales de "pulsación de teclas". De manera similar, un SelectionInListController (Controller adjunto a un cuadro de lista) podría absorber varios eventos de mouse hacia abajo, mouse hacia arriba y seguimiento de mouse dentro de una lista y tratarlos como un lista única de gesto de "selección".

Desde esta perspectiva, vemos que un sistema operativo moderno impulsado por eventos realiza la mayor parte de este procesamiento de gestos por nosotros".

Para resumir la lógica de Controller, puede ver que la función Controller es bastante coherente entre las variaciones de MVC a las que se ha hecho referencia. Como los controles (widgets) de Microsoft administran "las entradas de mouse y teclado desde el usuario", usted simplemente se suscribe a los eventos y señala el método que debe ejecutarse, el "Controller" dentro de sus controles inteligentes ejecuta el método por usted (administrado en el nivel de sistema operativo). Como tal, no tiene una necesidad de un Controller, como se indica claramente en el artículo “Twisting the Triad”. Sin Controller, le queda un patrón Model-View para aplicaciones de Windows. Tiene que tener esto en cuenta cuando estudia MVC y sus modelos de aplicación y presentación, porque sin Controller, no hay Triad (vea la Figura 3).

Figura 3 Sin Controller, solo ha sido Model-View (no Model-View-Controller)

Vale la pena mencionar que no solo fue Controller el factor que causó la ambigüedad con MVC. Con Smalltalk MVC, la lógica de negocio/dominio está en Model y con VisualWorks MVC, ApplicationModel contiene la lógica de "aplicación" necesaria para presentar uno o más objetos de negocio/dominio al usuario (vea la Figura 4). En el artículo “Twisting the Triad”, se abarca esto en más detalle. Si considera que Application Model y Presentation Model tienen las mismas funciones, con la diferencia distintiva de que Presentation Model "no puede" obtener acceso a View (Martin Fowler hizo una distinción clara para no sobrecargar los términos), entonces los desarrolladores de WPF pueden entender Presentation Model rápidamente porque en esencia es MVVM. John Gossman, padre fundador de MVVM, explica esto en su entrada de blog “PresentationModel and WPF” en bit.ly/pFs6cV. Al igual que Martin Fowler, tuvo cuidado de no sobrecargar los términos. Esto, en efecto, nos da un claro entendimiento de lo que es MVVM; es una "versión específica para WPF del patrón PresentationModel".

Figura 4 VisualWorks Model-View-Controller

Una vez que puede ver MVC en su verdadera dimensión, lo ayuda a entender los roles verdaderos de Model y View. Son, en esencia, las únicas dos ubicaciones para la lógica de negocio/dominio. Después de leer “Twisting the Triad,” puede ver que fueron las responsabilidades de Application Model que se movieron a Presenter y que no puede llegar y reemplazar Controller por Presenter (no tendría sentido, porque no son sinónimos).

El patrón MVP

Va más allá del alcance de este artículo adentrarse en MVP con la atención que merece; afortunadamente, existen diversos documentos que lo abordan, como “Twisting the Triad” y “Potel Paper,” los cuales puede descargar en bit.ly/dF4gNn (PDF).

Sin embargo, debo observar que en el artículo “Twisting the Triad” se señala un punto importante al que aludí, lo cual llevó a la evolución de MVC a MVP:

"Otra característica irritante de MVC, al menos con respecto a Dolphin, fue que la idea de un controlador no calzaba bien en el entorno de Windows. Microsoft Windows, igual que la mayoría de los sistemas operativos gráficos, proporciona un conjunto de widgets nativos desde los cuales se pueden construir interfaces de usuario. Estas "ventanas" ya incluyen la mayoría de las funciones de controlador que se representan como parte del control del sistema operativo subyacente".

También me gustaría destacar del artículo “GUI Architectures” de Martin Fowler su afirmación de que "A esta necesidad de manipular los widgets directamente muchas la vieron como una solución alternativa poco limpia y ayudó a desarrollar el enfoque Model-View-Presenter". Esto es importante de comprender, porque MVVM ha inculcado la mentalidad de Presentation Model en muchos desarrolladores de WPF; creen que es "mala programación" actualizar View directamente. Esto es verdadero para MVVM y Presentation Model, porque una vez que hace referencia a View, ya no puede volver a usar ViewModel con otra View (la razón principal para esta regla). Este factor limitante fue una de las razones por las cuales Smalltalk MVC evolucionó al patrón MVP. Con MVPVM, los desarrolladores pueden obtener acceso a View y ViewModel directamente (con acoplamiento ajustado), lo cual permite que View y ViewModel permanezcan desacoplados por completo (vea la Figura 5). Las View pueden volver a usar diferentes ViewModels y los ViewModels los pueden volver a usar diferentes Views (como verá más adelante cuando analice el patrón MVPVM); este es uno de los muchos grandes beneficios de MVPVM.

Figura 5 Model-View-Presenter, Controller supervisor

Andy Bower compartió la siguiente información sobre el tema conmigo para proporcionar más claridad:

"Quizás vale la pena señalar que el objetivo de todos estos patrones es la reutilización a través de la plugabilidad. Mantener el acoplamiento flexible siempre que sea posible y las interfaces tan pequeñas como se pueda ofrece una máxima reutilización en la manera en que los componentes se pueden volver a combinar.

Sin embargo, observe que Model tiene efectivamente dos interfaces que deben ser compatibles con cualquier View y Presenter asociado. Lo primero es la interfaz de llamada de la función estándar, que se usa para obtener/configurar valores y comandos de realización. Lo segundo es la interfaz de evento, que debe ser la misma que la esperada por View (patrón del observador). A esta combinación de interfaces se le puede llamara "protocolo".

Por ejemplo, en Dolphin MVP, un widget (tríada) de lista necesita tres componentes con protocolos compatibles. Un ListModel, ListView y ListPresenter".

Una vez que comprende por qué no quiere actualizar View directamente (y se da cuenta de que esta razón contribuyó a un nuevo patrón de diseño que le permitió volver a usar objetos de manera eficaz al eliminar la limitación de no poder actualizar View), entonces tiene la opción de aceptar las nuevas oportunidades que ofrece la evolución. Vive en un mundo Agile y (como su código) tiene que cambiar sus patrones de pensamiento "que la historia se repita".

El patrón MVPVM

Se me enseñó este patrón en los inicios del ciclo de vida de Prism, específicamente en Drop 7 de CompositeWPF. Perdido en todos los poderes místicos de Prism, reconocí el patrón MVP, lo cual me ayudó a encontrar cierta base. Rápidamente aprendí (tal como enseño a nuevos desarrolladores) a tan solo ir a Presenter para tener un punto de partida para deducir el código y la aplicación. Cómo la ejecución de código llega ahí se puede aprender después y no tiene que interferir con escalas de tiempo críticas; el impacto de las curvas de aprendizaje difíciles se puede administrar.

Las siguientes definiciones de los componentes de MVPVM tienen extractos de “Twisting the Triad” según corresponda; encontré esta información útil, integral y precisa, así que con el afán de presentarle la mejor información posible, simplemente citaré las definiciones de este artículo. Estas definiciones siguen siendo acertadas hoy en día para MVPVM (vea la Figura 6) como lo fueron para MVP por allá por marzo de 2000 cuando se escribió “Twisting the Triad”.

Figura 6 Model-View-Presenter-ViewModel

(Nota: Prisma es el contexto de este artículo, sin embargo, MVPVM funcionará sin Prism; los diversos componentes simplemente se acoplarán de manera ajustada a su implementación frente a resolverse (acoplados flexiblemente por el contenedor de inyección de dependencia de Unity o Managed Extensibility Framework [MEF].)

MVPVM: Model

"Estos son los datos sobre los cuales operará la interfaz. Suele ser un objeto de dominio y la intención es que tales objetos no deben tener conocimiento de la interfaz de usuario". —“Twisting the Triad”

Se requiere la separación de Model de ViewMode para abordar los asuntos de la inyección de dependencia y su uso dentro de la Capa de lógica empresarial (BLL) y la Capa de acceso a datos (DAL) para Create (Crear), Read (Leer), Update (Actualizar), Delete (Eliminar) y List (Enumerar) (CRUDL) datos persistentes. En MVPVM, solo la DAL tiene acceso a los objetos Model persistentes.

MVPVM: View

"El comportamiento de una vista en MVP es muy similar que en MVC. Es responsabilidad de la vista mostrar el contenido de un modelo. Se espera que el modelo active notificaciones de cambio adecuadas siempre que sus datos se modifiquen y estos permiten que la vista se 'cuelgue' del modelo que sigue el patrón Observer estándar. Al igual que sucede con MVC, esto permite que varias vistas se conecten a un modelo único". —“Twisting the Triad”

(Nota: usé la cita anterior para recalcar que MVP no es un patrón nuevo y que es ta válido hoy como lo era cuando MVP evolucionó a partir de MVC. Sin embargo, la cita sí hace referencia a “Model,” mientras que MVPVM usa “ViewModel”.)  

Con MVPVM, nunca hay necesidad de tener un código subyacente. Presenter tiene acceso a View y puede suscribirse a eventos, manipular controles y manipular la UI según sea necesario. Esto demostró ser beneficioso mientras desarrollaba la aplicación para varias plataformas que acompaña este artículo. User ListBox no respetaba el enlace de datos para el evento de cambio de selección, así que tuve que desarrollar una manera que funcionara para las tres plataformas (porque comparten el mismo código). Cuando se activa View, llamo a WireUpUserListBox (vea la Figura 7, línea 174) y uso View para obtener una referencia a mi control lstUserList control (el cual reside en DataTemplate). Una vez encontrado, lo conecto al evento SelectionChanged y actualizo la propiedad SelectedUser de ViewModel. Esto funciona en el escritorio, Silverlight y Windows Phone.

Figura 7 Beneficios de poder obtener acceso a View directamente

View no tiene conocimiento de ViewModel, así que no están acoplados de manera ajustada. Mientras ViewModel admita todas las propiedades a las cuales enlaza View, puede usar View fácilmente. Presenter es responsable de conectar Views a sus ViewModels al configurar su DataContext en el ViewModel correspondiente.

MVPVM: Presenter

"Aunque es responsabilidad de la vista mostrar los datos del modelo, es el moderador el que gobierna cómo puede manipularse y cambiarse el modelo mediante la interfaz de usuario. Aquí es donde reside el corazón del comportamiento de una aplicación. De muchas maneras, un moderador de MVP es equivalente al modelo de aplicación de MVC; la mayor parte del código que administra cómo funciona una interfaz de usuario está integrado en una clase de moderador. La diferencia principal es que un moderador se encuentra directamente vinculado a su vista asociada para que los dos puedan colaborar estrechamente en sus roles de suministrar la interfaz de usuario para un modelo determinado". —“Twisting the Triad”

Presenter tendrá dependencias de las interfaces para las BLL desde las cuales debe recuperar objetos de dominio (datos), como se muestra en el panel izquierdo de la Figura 8. Usará las instancias resueltas según se hayan configuradas en el módulo (vea la Figura 8, panel inferior derecho) o programa previo para obtener acceso a los datos y poblar ViewModel.

Figura 8 Código de módulo de seguridad

Generalmente, solo Presenter estará acoplado de manera ajustada en los componentes de MVPVM. Estará acoplado ajustadamente a View, ViewModel y las interfaces de BLL. No se supone que los moderados se vuelvan a utilizar; abordan asuntos específicos, así como la lógica o las reglas de negocio para esos asuntos. En casos en que se puede volver a usar un moderador en aplicaciones empresariales, probablemente un módulo se ajustará mejor a la tarea; es decir, se podría crear un módulo (proyecto) de inicio de sesión que podrían reutilizarlo todas sus aplicaciones empresariales. Si codifica contra una interfaz, el módulo se puede reutilizar fácilmente mediante tecnologías de inyección de dependencia como MEF o Unity.

MVPVM: ViewModel

"En MVP, el modelo es puramente un objeto de dominio y no hay expectativa de (ni vínculo a) la interfaz de usuario en absoluto". —“Twisting the Triad”

Esto evita que ViewModel se acople ajustadamente a una vista única, lo cual permite que lo usen diversas Views. De igual manera, ViewModel no tendrá ninguna lógica de negocio de aplicación, de manera que los ViewModels se pueden compartir fácilmente entre aplicaciones empresariales. Esto promueve la reutilización y la integración de aplicaciones. Por ejemplo, mire la Figura 8, panel superior derecho, línea 28. SecurityCommandViewModel reside en el proyecto Gwn.Library.MvpVm.xxxx (donde xxxx = Silverlight, escritorio o Windows Phone). Como se requerirá un User ViewModel en la mayoría de las aplicaciones, este es un componentes reutilizable. Tengo que tener cuidado de no contaminarlo con la lógica de negocio específica de la aplicación de demostración. Este no es un problema con MVPVM, porque la lógica de negocio la administrará Presenter, no dentro de ViewModel (vea la Figura 6).

(Nota: a medida que Presenter pueble las propiedades ViewModel, estas elevarán eventos NotifyPropertyChanged, lo cual alertará a View de que tiene nuevos datos; es responsabilidad de View actualizarse de acuerdo con los datos de ViewModel cuando se le notifique.)

Capa de lógica empresarial

Las BLL no tiene conocimiento de los datos persistentes de Model. Funcionan estrictamente con objetos de dominio e interfaces. Generalmente, usará la inyección de dependencia para solucionar su interfaz de DAL dentro de BLL, para poder salir más tarde de DAL sin afectar ningún código descendente. Fíjese en la Figura 9, línea 34, que estoy usando una implementación MockBll para IBusinessLogicLayer para mi aplicación de demostración. Posteriormente puedo reemplazarla fácilmente con una implementación de producción de la interfaz con una línea de código porque desarrollé contra una interfaz.

Figura 9 Registro de BLL, DAL y comandos

La lógica empresarial no se limita a las BLL. En la Figura 9, registro tipos con nombre (para IPresenterCommand) para poder usar la inyección de dependencia como fábrica. Cuando el usuario hace clic en un botón (líneas 29 a 33 en la Figura 10), el parámetro de comando lo resuelve (le crea instancias) la clase básica y se ejecuta el comando correspondiente. Por ejemplo, LoginCommand (Figura 8, panel superior derecho) es un comando que activará UserManagerView. Todo lo que se necesitó para conectar esto fue un comando Button en XAML y una entrada en SecurityModule (vea la Figura 8, panel inferior derecho, línea 32).

Figura 10 DataTemplate para UserCommandViewModel

Capa de acceso a datos

Los datos de dominio persistentes se podrían almacenar en bases de datos SQL o archivos de texto o XML, o bien se podrían recuperar desde un servicio REST. Con MVPVM, solo DAL dispone información específica necesaria para recuperar datos. DAL solo devolverá objetos de dominio a BLL. Esto anula la necesidad de que BLL tenga conocimiento de las cadenas de conexión, controladores de archivos, servicios REST, etcétera. Esto mejora la escalabilidad y la extensibilidad; puede pasar fácilmente su DAL de un archivo XML a un servicio de nube sin afectar ningún código existente de DAL ni el archivo de configuración de la aplicación. Siempre y cuando sus nuevas pruebas de unidad DAL funcionen para los procesos CRUDL, puede configurar la aplicación para que use la nueva DAL sin afectar las aplicaciones actuales y su uso.

Comprender la historia, beneficiarse de la experiencia

Gracias al equipo de patrones y prácticas, he podido obtener éxito para mis clientes al usar tecnologías de punta y patrones como MVPVM, sin fallar. Descubrí que al seguir el ritmo del equipo, sus tecnologías y patrones, mientras surgen tecnologías y patrones más nuevos, puedo recurrir a experiencias pasadas para ayudarme a encontrar el camino más fácilmente en territorio nuevo.

MVP es un patrón constante y coherente que he usado desde los inicios de mis estudios de arquitectura en que usaba proyectos de patrones y prácticas. Para apreciar MVP en plenitud, se debe comprender su historia, sobre todo los componentes de MVC. Esto no es fácil, debido a los diversos factores analizados.

Pero al comprender nuestro pasado, y el motivo de nuestra evolución, podemos entender más rápidamente la necesidad y la eficacia de patrones más nuevos. Incluso con Prism y toda su complejidad y magia, podrá omitir una difícil curva de aprendizaje con solo conocer estar historia y apreciar la necesidad de patrones nuevos. En todos los proyectos exitosos en que he estado involucrado desde la aparición de este patrón en los inicios de Prism, MVPVM no ha revelado problemas, obstáculos o paredes de ladrillo (a través de la evolución parecen haberse eliminado), con lo que ha permitido que los desarrolladores aumenten la velocidad mientras creamos aplicaciones que son escalables, extensibles y estables.

Bill Kratochvil , trabaja en forma independiente como tecnólogo y arquitecto jefe de un equipo de élite de desarrolladores en el desarrollo de un proyecto confidencial para una empresa líder en la industria médica. Su empresa, Global Webnet LLC, tiene su base en Amarillo, Texas.

Gracias a los siguientes expertos técnicos por su ayuda en la revisión de este artículo: Andy Bower, Christina Helton y Steve Sanderson