Estoy escribiendo una aplicación simple de formularios web ASP.NET. Quiero mejorar el código implementando cualquier patrón de diseño con el que se logre la abstracción y aumente la capacidad de administración y la comprensión.
¿Qué patrón se recomienda? Proporcione también enlaces a aplicaciones de muestra.
Respuestas:
Puede considerar usar el patrón MVVM Modelo-Vista-Vista Modelo . Es un derivado de MVC, pero está diseñado / destinado a ser utilizado exactamente en la situación que usted describe. Hay una gran cantidad de información en el sitio de MSDN si no tiene ganas de buscarlo en Google.
MVVM facilita una separación clara del desarrollo de la interfaz gráfica de usuario (ya sea como lenguaje de marcado o código GUI) del desarrollo de la lógica de negocios o la lógica de back-end conocida como el modelo (también conocido como el modelo de datos para distinguirlo de la vista modelo). El modelo de vista de MVVM es un convertidor de valor, lo que significa que el modelo de vista es responsable de exponer los objetos de datos del modelo de tal manera que esos objetos se administren y consuman fácilmente. A este respecto, el modelo de vista es más modelo que vista, y maneja la mayoría, si no toda, la lógica de visualización de la vista (aunque la demarcación entre qué funciones son manejadas por qué capa es un tema de discusión y exploración en curso).
Con el formulario web ASP.NET, normalmente usa el patrón Presentador de vista de modelo .
GlenH7 mencionó en su respuesta MVVM; Si bien es un patrón elegante, ASPX Webform simplemente no tiene un gran soporte para eso. MVVM es más popular en el mundo WPF.
Respuesta corta : mire el patrón MVP que evita posibles problemas de formas de código ASP.NET al acoplar (desacoplar) su vista y lógica.
También puede ir un paso más allá y ver esta comparación: MVC, MVP, ASP.NET .
Las siguientes publicaciones son buenos puntos de entrada y ejemplos:
Lo único que debe evitar a toda costa es el antipatrón de WebForms de poner lógica en su código subyacente. Ya sea que use MVP o no, sus archivos de código subyacente deben ser muy escasos por el bien de su cordura.
Sin embargo ... su requisito declarado es muy abstracto:
Quiero mejorar el código implementando cualquier patrón de diseño con el que se logre la abstracción y aumente la capacidad de administración y la comprensión. ...
... y para esos fines parece que buscas "patrones de diseño" como una especie de receta. Incluso cita "abstracción" como un requisito.
El código ya existente que se encuentra en una aplicación ya existente generalmente no se beneficia de los intentos de "mejorarlo". Debe basar completamente sus esfuerzos, no en abstracciones como "patrones de diseño", sino en la aplicación misma, exactamente como está ahora.
Durante muchas décadas, he examinado más de cincuenta aplicaciones diferentes que estaban o aún están en servicio y puedo ver las "balas de plata" de antaño a medida que iban y venían, cada una imponiendo una "nueva" forma de hacer cosas que en realidad nunca reemplazó nada. Ambos métodos siguen ahí. La "manejabilidad y comprensibilidad" se habrían mejorado mucho a largo plazo si esta o aquella "bala de plata" nunca se hubiera intentado.
El concepto completo de "patrones de diseño", en mi opinión, es que son una forma de iniciar una conversación útil y sugerir posibles alternativas. Pero no son recetas.
MVVM es posible en .NET 4.5 con enlace de modelo y el uso de controles enlazados con plantilla como FormView.
Aquí está la técnica que uso:
Diseño ViewModels para cada UserControl y UserControl anidado y luego uso un FormView que siempre está en EditMode, donde incluyo los controles que se unen a las propiedades del modelo mediante expresiones de enlace.
Configuré SelectMethod y UpdateMethod de FormView. El primero devuelve el ViewModel y el segundo llama a TryUpdate () en él. En las devoluciones, siempre llamo al método de actualización de FormView en Preload o Load. De esa manera, ViewModel siempre está actualizado desde la vista.
Ejecuto la lógica dentro del ViewModel y en PreRender vuelvo a vincular la vista para aplicar cualquier cambio. La clave de este método es inyectar el ViewModel en la vista (UserControl) fuera de la vista (por ejemplo, en el nivel de página) y, por supuesto, asegurarse de que sea serializable y almacenado en caché en ViewState o en cualquier otro lugar que elija.
Finalmente, deshabilito el ViewState en todos los controles, ya que están controlados por el ViewModel con estado en caché y no necesitan su propio estado.
Esta técnica nunca me falló hasta ahora y solo desearía poder encontrar una solución para el comando / enlace de botones también, como WPF.