model - ¿Compra la historia de reutilización para la capa de presentación en MVP y sus variaciones?
view reusability (10)
Además de los beneficios de las pruebas unitarias, lo que escuché sobre el patrón de MVP fue que la capa de presentación es reutilizable. Entonces, diseñaría una capa de presentación y la usaría para WinForms (rich) y Web.
Actualmente estoy trabajando en una aplicación de formularios para Windows en .NET con la posibilidad de crear una interfaz de usuario web en el futuro. Sin embargo, cuando estoy diseñando la capa de presentación y la interacción entre la capa de IU, no estoy seguro de si esta noción de reutilización vale la pena. A veces siento que estoy "embruteciendo" mi presentación para la posible IU web, cuando puede ser mucho más cuando está diseñada específicamente para la interfaz de usuario de formularios de Windows.
Entonces, ¿cuántos de ustedes están cosechando los beneficios de la capa de presentación reutilizable? ¿Funciona esta reutilización en el mundo real?
Creo que puede estar malinterpretando el papel o el presentador.
Yo diría que el presentador no debería tener casi nada que ver con la IU, es decir, la forma en que se muestra la información.
El presentador debe tomar cualquier entrada de la IU (ya sea web o winform), comenzar el procesamiento necesario en el nivel del controlador y mantener la salida.
La IU debe tener un control total sobre cómo se utiliza esa devolución.
Ejemplo:
Supongamos que extrae datos de una base de datos sobre un automóvil.
Puede pasar el número de identificación del vehículo de la IU al presentador y luego pedirle que devuelva los datos. Cuando finalice el procesamiento, contendrá los datos devueltos: supongamos que tiene la marca, el modelo, el año y la última fecha de registro.
Desde su UI, debería poder mostrar esto como lo desee, y esto hace que el presentador sea reutilizable. Puede mostrar los 4 elementos en una forma de ganar, pero en una interfaz de usuario web para móviles puede mostrar los conceptos básicos (marca, modelo y año).
MVC es un buen patrón para usar incluso si terminará usándolo solo para una interfaz. Le ayuda a diseñar aplicaciones con partes limpias y separadas. Esto trae varios beneficios.
Facilita la prueba automatizada de piezas, por ejemplo, puede llamar a sus modelos directamente, sin la necesidad de GUI.
Como hay una línea limpia de separación, es más fácil rediseñar partes de la aplicación, sin romper otro código (por ejemplo, rediseñar la GUI).
Tener varias partes más pequeñas (e independientes como sea posible), en lugar de una gran confusión de cosas, hace que sea más fácil depurarlas.
Introducir nuevos programadores al código será más fácil ya que pueden explorar una parte lógica a la vez.
En términos generales, MVC es una buena manera de diseñar aplicaciones, ya que le proporciona una forma natural de encapsular su aplicación a alto nivel.
El valor de MVC / MVP realmente radica en dos separaciones diferentes.
La separación entre su capa de presentación y sus modelos (como quiera que decida implementarlos) es uno de los principales diseños de software más importantes para cualquier cosa que no sean sistemas simples. Si tiene lógica comercial o lógica no visual en su aplicación, definitivamente verá los beneficios de esa separación.
La separación entre la capa de presentación y el controlador me parece un poco menos importante. En aplicaciones de cliente enriquecido, rara vez verá beneficios de esta separación; en las interfaces web, es mucho más común (por ejemplo, ASP.NET aspx y código subyacente o J2EE jspx y servlet).
Tal vez no entiendo completamente la forma en que ha explicado MVP, pero no diría que uno de los beneficios es la reutilización de la capa de presentación, más bien, diría que el beneficio principal es la reutilización de los modelos . Este es también uno de los principales beneficios de usar cualquier sistema n-tier. Si desea expandir y construir un nuevo tipo de front-end (por ejemplo, WinForms, WPF, etc.), puede hacerlo sin tratar de separar toda su lógica de la aplicación web que acaba de crear.
Estoy de acuerdo con chills42: el objetivo de MVP no es hacer que el presentador sea tan genérico que pueda ser utilizado con cualquier tecnología UI. El objetivo es hacer genéricos los modelos y (tal vez) los controladores para que pueda construir una interfaz de usuario con la tecnología que desee.
Una vez más, podría ser que no te estoy entendiendo bien, pero el enlace de datos no es particularmente relevante para tu pregunta (lo que quiere decir que no veo la conexión). El objetivo es este:
Usted diseña su lógica de aplicación, también conocida como controladores (p. Ej., Cuando Bob envía una factura, el sistema hace x, y, yz, y luego muestra a Bob la lista de facturas).
Usted diseña los datos de su empresa, también conocidos como modelos (por ejemplo, Facturas, que tienen una lista de artículos de línea).
Ahora, te estás preguntando, ¿dónde diablos está la interfaz de usuario? Tienes algo que sabe cómo guiar tu proceso y tienes todos los datos que necesitas para hacerlo, así que solo necesitas algo que te muestre cómo se ve. Aquí es donde entra el presentador.
Diseñas una aplicación .NET WinForms que interactúa con tus controladores y modelos. Usted crea una forma hermosa que proporciona a sus usuarios una forma de crear facturas. Luego, pasa toda la información a los controladores que la toman, la procesa usando los modelos y luego le dice qué hacer a continuación. Su aplicación WinForms felizmente sigue su manera feliz (desinformada) y hace lo que se le dice, recibiendo datos para el siguiente formulario y mostrándolo.
Luego, su jefe entra y dice: "Oye, Jiho Han, esta aplicación tuya es un éxito total. Necesito que me construyas una aplicación ASP.NET y un procesador por lotes que también harán todo esto.
Mierda. Él quiere que tú ¿qué? Oh no hay problema. Usaste MVP. Todo lo que necesita hacer es crear una interfaz de usuario ASP.NET (que siga los estándares web, por supuesto) que actuará como la cara bonita para todos sus datos. No hay problema, tres días, envíelo.
Este es el beneficio de MVP. No tuvo que volver a escribir toda su lógica de aplicación; no tuvo que escribir toneladas de consultas para obtener sus datos en un formato diferente; no tienes que hacer realmente ningún trabajo. Quiero decir, hacer interfaces de usuario es divertido, ¿verdad? Ahora depende de usted determinar si cree que vale la pena el tiempo, pero en casi cualquier software real se espera que tenga algún tipo de separación de estos componentes, ya sea MVP o algo más empresarial como n-tier.
escalofríos42,
Creo que puede estar malinterpretando el papel o el presentador.
Creo que entiendo muy bien el papel del presentador.
No dudo que PUEDAS hacer que el presentador sea genérico para que funcione para cualquier UI. Mi pregunta es si vale la pena el esfuerzo mientras se pierde la oportunidad de aprovechar las ventajas que una determinada plataforma de interfaz de usuario puede proporcionar.
Piensa en la unión de datos en WinForms. Al implementar ciertas interfaces ( IDataErrorInfo , INotifyPropertyChanged , IEditableObject , etc.) su presentador puede hacer que la UI sea mucho más simple con menos código. Algunos pueden decir que la unión de datos no es una ventaja, eso no viene al caso. Muchas de estas interfaces no tienen sentido para la web aunque probablemente no la perjudiquen. Podría crear un adaptador para WinForms para fines de enlace de datos. Entonces tengo otra capa. La pregunta es, ¿vale la pena el esfuerzo?
Ed Altorfer,
Estoy un poco confundido por lo que te refieres como controlador.
Usted diseña su lógica de aplicación, también conocida como controladores (p. Ej., Cuando Bob envía una factura, el sistema hace x, y, yz, y luego muestra a Bob la lista de facturas).
Usted diseña los datos de su empresa, también conocidos como modelos (por ejemplo, Facturas, que tienen una lista de artículos de línea).
Pero según sus declaraciones, parece que los controladores son lo que contiene la lógica de la aplicación (¿lógica comercial?) Y sus modelos son simplemente titulares de datos.
Por lo que entiendo, P significa Presentación. P se refiere a la lógica de presentación: la mejor forma de presentar al usuario la información empresarial subyacente. La lógica / reglas comerciales reales se containe en la capa del modelo. De hecho, lo que usted llama controladores también sería parte de la capa del modelo: el M.
En cualquier caso, su ejemplo con respecto al jefe "exigente" parece sacado directamente del libro de texto, todos lo sabemos. Eso no es lo que estoy discutiendo.
Nuevamente, si P es para la presentación, sus WinForms y Web pueden tener un flujo completamente diferente para sus necesidades de presentación. Por no mencionar la consola uno para la aplicación por lotes, donde es posible que ni siquiera necesite la capa P. El enlace de datos hace que la capa de interfaz de usuario de WinForms sea mucho más simple: la tecnología de enlace de datos de V funciona como está diseñada. Intente comparar las fuentes de las aplicaciones de enlace de datos frente a las de no enlace de datos. En el escenario sin enlace de datos, hay más partes móviles que debe administrar usted mismo. Tienes más control, pero aún así tienes que administrarlo. En mi opinión, la vinculación de datos es importante para la forma en que escribo el P.
No estoy en desacuerdo con que PUEDAS hacer que una capa P funcione para todo tipo de UI, pero me temo que, al hacerlo, debes comprometerte con el mínimo común denominador para todas tus UI. Y también que podría estar presionando más de la lógica de presentación en la capa UI, lo que a su vez hace que las pruebas unitarias sean más difíciles.
Espero que haya aclarado mi dilema original. Me temo que me está faltando la capacidad de expresarme adecuadamente ...
Estás haciendo un buen trabajo al explicarte, sin preocupaciones. :)
Tenga cuidado de no confundir la lógica de la aplicación con la lógica comercial. La lógica de la aplicación a veces se denomina control de proceso de la aplicación , que probablemente sea un nombre más apropiado para ella. Esto es básicamente acciones del usuario y respuestas del sistema. Por ejemplo, Paso 1: el usuario inicia sesión, Paso 2: el usuario hace clic en "Crear nueva factura", Paso 3: el usuario envía información básica, Paso 4: el usuario agrega líneas, Paso 5: el usuario envía la factura a la base de datos de facturas.
Los pasos que he descrito a continuación son el control del proceso que se aplica a cualquier interfaz de usuario que diseñaría para su aplicación de factura. La lógica empresarial, por otro lado, está encapsulada en sus modelos. P es para presentación, sí, pero no es para lógica de presentación. En la mayoría de los casos, P se va a referir a su contenido orientado al cliente (por ejemplo, ASPX, JSPX, Ruby on Rails views, etc.) - es estrictamente marcado. En otras palabras, sus controladores proporcionan algún comportamiento para su capa de presentación.
Dadas estas definiciones, probablemente puedas ver cómo, si creaste tus controladores y modelos correctamente, serían completamente independientes de la interfaz de usuario. No tendrías que atender al mínimo común denominador porque simplemente encapsulan tu lógica de proceso y tu lógica de negocios, permitiendo que tu capa de presentación se adapte al medio a través del cual expones esa lógica (por ejemplo, Internet, consola o computadora de escritorio). aplicaciones).
Como nota al margen, a veces los controladores y los modelos están expuestos de alguna otra manera abstracta (como servicios web) para que pueda tener un conjunto de UI o servidores web para equilibrar parte de su tráfico entrante y aún puede aprovechar el mismo back-end .
¿Espero que esto ayude un poco?
Compro la historia de la reutilización porque funcionó para mí una vez, y porque no espero que cambiar de un tipo de interfaz de usuario a un tipo totalmente diferente sea trivialmente fácil.
En general, y en su caso, espero tener que modificar bastante el Presentador. Y eso está bien, para eso está ahí. Es esencialmente un adaptador entre la interfaz de usuario y la lógica del dominio. Y dado que ayuda a mantener la lógica del dominio fuera de la interfaz de usuario, hará que el intercambio de interfaces de usuario sea mucho más fácil.
Ah, y por cierto, las aplicaciones web están empezando a ser mucho más poderosas. ¡Bien puede tener que mejorar su Presenter para la web!
Micro
Creo que tienes toda la razón con tu sentimiento de "embotamiento".
La reutilización es uno de los agujeros de rata más profundos, oscuros y desagradables por los que un proyecto puede desaparecer, hablando de aproximadamente 15 años de experiencia de desarrollo de OO durante el cual la reutilización se pregonó como uno de los principales beneficios que obtendríamos.
Diseñar para su reutilización es como diseñar para el rendimiento: debe ser un principio básico pero, en la mayoría de los casos, prestar demasiada atención al inicio hace que su proceso de desarrollo se empantane y hace que generalice demasiado todo.
Mi recomendación habitual es implementar la GUI más compleja y flexible primero y luego refactorizar a una arquitectura genérica más reutilizable. Dependiendo del tamaño del proyecto, hazlo en un prototipo con algunos objetivos explícitos sobre lo que estás evaluando. Luego puede archivar el prototipo y conservarlo mientras lleva las lecciones aprendidas y algunos códigos al proyecto principal.
Nota: el prototipo, si está explorando arquitecturas de GUI, necesita usar la tecnología que pretende utilizar y es profundo y angosto en lugar del prototipo tradicional de la GUI que se hace para demostrar la apariencia de GUI.
La reutilización permitida por el diseño de MVC no es tal que la misma vista / presentador puede presentar el mismo modelo / controlador a diferentes salidas, sino que se pueden presentar diferentes conjuntos de modelo / controlador en una vista común.
Un sistema, a medida que madura, es probable que necesite varias vistas: una interfaz web, un editor de escritorio, una API de script automatizada y varios modelos diferentes: la facturación para el cliente A se realiza por pedido, pero el cliente B la necesita Trimestral por departamento de atención al cliente.