arquitectura MVC + WCF + TDD o DDD

Aquí estamos de nuevo en la encrucijada.arquitectura MVC + WCF + TDD o DDD

quiero intentar implementar, al menos durante los próximos 3 años, una forma simple y probada de diseñar mis aplicaciones. Cada vez que voy a comenzar un proyecto, parece que es la primera vez debido a la gran cantidad de "formas" de crear sitios web en estos días.

tengo este código de muestra que obtuve de este paquete que compré llame a Design Pattern Framework 4 C#. Entre los múltiples proyectos que tienen, hay uno, que se llama, Patrones de diseño en acción. Puede descargarlo desde aquí https://skydrive.live.com/redir?resid=B853B0DB724C30E5!16735&authkey=!AOeHSAWa_P4vzzU

Mi pregunta, después de echar un vistazo a esa solución, ¿Qué es bueno, malo, qué conservaría, qué eliminaría, qué es innecesario, etc. sobre este ejemplo?

Entiendo que están tratando de mostrar varios clientes y también varios DAO. Pero en general, ¿esta arquitectura sería una que tomaría como una "plantilla"? Gracias.

Fuente

2012-08-23 Pepito Fernandez

Las únicas respuestas que puede obtener son las siguientes: "Creo que XYZ es bueno porque lo uso" –

No existe una solución mágica, una cura para todos los tamaños. Usas lo que sea más productivo. –

Mi pregunta, después de echar un vistazo a esa solución, Lo que es bueno, malo, ¿Qué guardarías, qué eliminarías, qué es innecesario, etc. etc. sobre este ejemplo?

Después de un rápido vistazo, aquí es lo que diría:

Con respecto a la etiqueta DDD en su pregunta, esto claramente no es un dominio de la arquitectura impulsada. Los objetos de negocio se ven anemic aparte de algunas simples reglas de validación y muchos de los elementos básicos de una arquitectura DDD no están presentes (agregados, objetos de valor, etc.)
A menos que haya perdido algo, la mayoría de las operaciones comerciales son operaciones CRUD que no son realmente representativas de una aplicación empresarial del mundo real.
Hay una capa de Servicio gorda con una clase ActionService grasa que básicamente parece manejar todos los casos de uso de la aplicación. La buena noticia es que trata los casos de uso de forma agnóstica (hasta donde puedo decir, los objetos de Solicitud y Respuesta que manipula son independientes del mecanismo de entrega). Ser gordo es menos deseable, ya que la clase incluye demasiadas responsabilidades (SRP).
Usar repositorios en el lado del cliente y DAO en el lado del servidor parece extraño, pero ¿por qué no?
Si realmente es impulsado por pruebas, ¿por qué no incluir todas las pruebas unitarias en lugar de solo una muestra?

Aparte de eso, las capas están bien diseñados y, como las capas de presentación múltiples muestran, no debería ser difícil de sustituir un front-end para otro o de un almacenamiento persistente para otro.

Fuente

2012-08-24 12:20:15 guillaume31

Gracias por la respuesta. Esta no es una "aplicación completa".Creo que querían mostrar más o menos cómo funcionan los diferentes patrones, etc. Después de leer un poco sobre DDD, me di cuenta de que no tiene nada que ver con DDD. Creo que la razón por la que tienen repositorios en el cliente es para poder unitarlo. Eso es lo que dice la documentación. Como cuestión de hecho, esta muestra también viene con una muestra de formulario de Windows, wpf, webforms (mvp). pero lo eliminé porque era irrelevante para mi pregunta. Como cuestión de hecho, el proyecto MVC es el único que usa un repositorio para acceder al servicio. –

Supongo que esta muestra sería mejor usarla con una aplicación liviana que no va a crecer. Algo rápido ¿De acuerdo? –

Ligero no es necesariamente cómo lo describiría. Puedes sentir que la arquitectura fue diseñada para ser modular y se agregaron muchas capas de abstracción para hacer posible esa modularidad. Como dije, podría cambiar una capa periférica por otra con bastante facilidad, lo que no es el caso con aplicaciones ligeras donde la interfaz de usuario básicamente habla directamente con la base de datos. – guillaume31

Arquitectura del Sistema es muy similar a la construcción de la arquitectura:

No hay una sola manera "correcta"
Cada uno tiene sus propias opiniones sobre la "mejor"
La "mejor" la arquitectura depende de la contexto y las necesidades
Estilos y métodos cambian con el tiempo

Hay muchos factores que intervienen en choosi ng an architecture:

Time to Market: ¿cuánto tiempo tiene que hacer algo?
Mantenibilidad: ¿será el único que lo mantendrá? ¿Fuente abierta?
Extensibilidad: ¿será un sistema cerrado o abierto?
Escalabilidad: ¿utilidad simple o escala empresarial?
Plataforma: ¿web o nativa? ¿De escritorio o móvil?

Todo eso, para decirlo, me sorprendería si pudiera encontrar un marco completo que se adapte a cada proyecto que tendrá durante los próximos 3 años. Piense en MVC, WFC, TDD, DDD, etc. como herramientas que puede usar para construir el derecho un sistema que satisfaga las necesidades de esa situación.

Mi opinión es: utilice los conceptos que pueda comprender (y pueda enseñar a otros si es necesario) siempre que se adapte a la situación particular.

Fuente

2012-08-23 15:34:06

aún mejor con la arquitectura del sistema en el que podemos entrar y cambiar nuestros edificios:) –

Entiendo su punto. Estoy tratando de tener un equilibrio entre todos los elementos involucrados en una aplicación web. Supongo que lo que más me confunde es la abrumadora cantidad de "mejores prácticas" que descubres por ahí. La realidad es que muchas veces se contradicen. Estoy tratando de usar la solución anterior para establecerme a mí mismo una "plantilla de trabajo" ya que todas mis aplicaciones están prácticamente estructuradas de la misma manera. Gracias por tu respuesta. –

Como dice @d_stanley, MVC, WCF, TDD y DDD son herramientas, marcos, metodologías, una colección de mejores prácticas, etc. TDD tiene un fanatismo que paralizaría un proyecto si lo sigues al pie de la letra, DDD como Patrones de diseño es un juego de herramientas que puede elegir (no debe intentar usarlo en todos los proyectos). MVC y WCF son marcos funky para facilitar la creación/gestión de sitios web y comunicaciones, respectivamente, y serían buenas opciones en general. –

Elija una.
Pruébelo.
Refactor/cambie si no es adecuado para usted.

Lo más importante es asegurarse de utilizar patrones que son refactorables.Si está utilizando TDD y encuentra que puede inyectar sus dependencias, falsificaciones, etc., esto facilitará el proceso de refactorización. Tres años es mucho tiempo para usar cualquier patrón dado. Un amigo le dijo que si no mira el código de 6 meses atrás y pensar que es una mierda, así que no puede estar aprendiendo lo suficiente:)

Fuente

2012-08-23 15:55:55

Tiene toda la razón en ver el código que tiene seis meses de antigüedad. Eso es exactamente lo que trato de hacer: no quedar atrapado en el lado "perfeccionista" de la codificación. Encontré este fragmento de código, parece muy robusto, también un poco genérico, pero al menos te da una idea de una de las muchas maneras de hacer las cosas "correctamente". –

Respuesta

Cuestiones relacionadas