Patrones de diseño comunes para su uso en aplicaciones web MVC

Question

Estoy tratando de entrenar a algunos tipos en la construcción de aplicaciones web. Ellos entienden y usan MVC, pero estoy interesado en otros patrones comunes que usas para crear aplicaciones web.

Entonces, ¿qué patrones ha encontrado que encajan perfectamente en una aplicación MVC adecuada? Tal vez algo para procesos asíncronos, tareas programadas, manejo de correo electrónico, etc. ¿Qué desea saber que debe buscar o evitar?

No es que importe para esta pregunta, pero estamos usando ASP.NET y Rails para la mayoría de nuestras aplicaciones.

Answer 1

Una vez que ingresa a MVC, puede valer la pena explorar patrones que van más allá del libro "Gang of Four", y entrar en "Patterns of Enterprise Application Architecture" de Martin Fowler.

El patrón Registry puede ser útil para hacer que los objetos conocidos estén disponibles en toda la jerarquía de objetos. Esencialmente un sustituto del uso de datos globales.

Muchos frameworks MVC también emplean los patrones Front Controller y Two-Step View.

El "Modelo" en MVC está mejor diseñado como el patrón Domain Model, aunque algunos marcos (liderados por Rails) conflate el Modelo con el patrón ActiveRecord. A menudo advise, la relación entre un modelo y ActiveRecord debe ser HAS-A, en lugar de IS-A.

Lea también sobre ModelViewController en la wiki de Portland Pattern Repository. Existe una buena discusión sobre MVC, orientación a objetos y otros patrones que complementan a MVC, como Observer.

Answer 2

Lo más probable es que también recomiende algún tipo de Inyección de Dependencia (Inversión de Control). Probablemente sea el "patrón" suplementario más importante que se debe usar.

Answer 3

Esta pregunta es tan abierta que es difícil dar una respuesta correcta. Podría decirle que Observer patrón es importante en MVC (y para webapplication) y sería una buena respuesta. Sobre todos los patrones de diseño que existen son comunes en la gran aplicación web. Necesitará utilizar algunos Fábrica para construir objetos complejos y para acceder a alguna sección requieren algunos Fachada.

Si quieres más "consejos" o buenas prácticas en lugar de patrón de diseño, sugeriría que usted utilice IoC y el uso de buena Framework en lugar de empezar desde cero. Puedo sugerirle que explique el beneficio de tener un buen motor ORM para impulsar su capa de persistencia más rápido también (generalmente también puede provenir del Framework).

Answer 4

No lo mires desde el aspecto de qué patrones usar con tu enfoque de desarrollo, sino más bien cómo aplicar patrones problema por problema. Las decisiones arquitectónicas tomadas para el proyecto proporcionan la misma indicación de qué patrones usar como lo dictará la experiencia de otras personas.

Dicho esto, descubrí que soy un fanático del modelo de proveedor por tener múltiples opciones para realizar una sola tarea con la facilidad de implementación agregada. Además, el patrón de unidad de trabajo es excelente para establecer límites transaccionales. En gran parte, sin embargo, las necesidades de arquitectura y negocios dictan el enfoque que se toma para cualquier cambio de código o desarrollo nuevo.

Tanto como amo los patrones, siempre me da miedo verlos sobre usados. Personalmente, he visto personas que los han utilizado solo para usarlos, y en realidad ha hecho que el código sea más difícil de mantener y más estrechamente acoplado de lo que debería haber sido. Además, es bueno conocer ambos lados del argumento de patrones. Un buen conocimiento de patrones debe completarse con (también se considera un patrón, por sí solo) conocimiento de anti-pattern.