es decir ¿El MVP sigue siendo la siguiente mejor opción cuando MVC no es una opción?Refactorización de una aplicación heredada de WebForms para separar mejor las preocupaciones
Pensé que podría preguntar esto aquí, ya que estoy seguro de que hay otros como yo que no tienen el lujo de estar en un proyecto de campo verde y quieren refactorizar una interfaz de usuario de formularios web para una mejor separación de presentación desde objetos comerciales ...
Estoy trabajando en una aplicación heredada encargada de agregar requisitos adicionales relativamente pequeños, mejoras y correcciones de errores.
La parte de la aplicación que menciono aquí se puede caracterizar como la interfaz de usuario para un conjunto de operaciones CRUD sobre objetos comerciales que se conservan en una base de datos relacional.
La interfaz de usuario existente usa un control MultiView para navegar entre la edición de los objetos comerciales asociados (asociaciones one-one o one-many/parent-child). Sí, así es, todo en una página. Desafortunadamente, hay un uso muy moderado de UserControls, por lo que el marcado y el código subyacente tienen cientos de líneas de longitud.
En cada Vista, un FormView gestiona el CRUD sobre los objetos comerciales a través de varios ObjectDataSources. Dentro de ItemTemplate de cada FormView, varios servidores controlan los datos de los campos o métodos en ObjectDataSource.
Me gustaría introducir más separación de preocupaciones y obtener algunas de las resmas de código fuera de la página de código subyacente.
Mi investigación sugiere hasta ahora para mí que me podría considerar:
Use a flavour of Model View Presenter; más específicamente - use an ObjectContainerDataSource from the Web Client Software Factory para facilitar el puente entre la interfaz de usuario actual y un conjunto de nuevas clases de Presentador.
Compila de nuevo desde cero con una estructura MVC (no es una opción).
Deje solo; un patrón de MVP solo se justifica si necesito volver a usar mi Presentación en diferentes escenarios de IU?
Si me conformo con (3) me gustaría saber cómo comenzar la refactorización para una mejor separación de la presentación.
¿Qué harías? otras ideas recibidas con gratitud ...
He aquí algunos antecedentes más para cualquiera que esté interesado:
El dominio está en la investigación farmacéutica, pero que es bastante irrelevante y se puede pensar que es línea- como bastante típico of-business: configuración del usuario de una familia de configuraciones que forman las condiciones de funcionamiento de otra parte de la aplicación.
La capa de objeto de negocio ya se ha creado de manera muy uniforme. Aunque puede que no me guste, no puedo justificar necesariamente el cambio. Cada objeto es su propio Repositorio/Objeto de acceso a datos, ya que hay métodos estáticos para 'obtener ID' y 'obtener lista por criterio'. Donde sea posible, las operaciones comunes se implementan en una clase base abstracta. Cada objeto comercial delega el trabajo de acceso a datos a una capa de acceso a datos que hace uso de ADO.NET 2.0 Mecanismos de fábrica del proveedor para permanecer relativamente abstraídos de un proveedor concreto. A este respecto, comparte mucho en común con cualquier aplicación que use el Bloque de aplicaciones de acceso a datos de Microsoft Enterprise Library.
Hay pruebas de integración bastante exhaustivas escritas en NUnit que configuran una base de datos de prueba desde cero, por lo que tardan años en ejecutarse, pero al menos verifican que todo funcione como debería (en algún punto del pasado ;-). Casi no hay pruebas de unidades verdaderas en su lugar (todavía).