Desarrollo de la aplicación N-Tier. ¿En que dirección?

Question

Suponiendo que está implementando una historia de usuario que requiere cambios en todas las capas, desde la interfaz de usuario (o la fachada de servicio) a la base de datos.

¿En qué dirección te mueves?

• ¿De la interfaz de usuario a la capa empresarial del repositorio a la base de datos?
• ¿De la base de datos al repositorio de la capa empresarial a la interfaz de usuario?
• Depende. (¿En qué?)

Answer 1

La mejor respuesta que he visto a este tipo de pregunta fue suministrada por los chicos de Objetos Atómicos y sus Presentador primero patrón. Básicamente, es una implementación del patrón MVP, en la que (como su nombre lo indica) comienzas a trabajar desde el Presentador.

Esto le proporciona un objeto muy liviano (ya que el presentador está básicamente allí para reunir datos del Modelo a la Vista y eventos de la Vista al Modelo) que pueden modelar directamente su conjunto de acciones de usuario. Cuando se trabaja en el Presentador, la Vista y el Modelo generalmente se definen como interfaces y se burlan, por lo que su enfoque inicial es definir cómo el usuario interactúa con sus objetos.

Por lo general, me gusta trabajar de esta manera, incluso si no estoy haciendo un patrón MVP estricto. Me parece que centrarme en la interacción del usuario me ayuda a crear objetos de negocios con los que es más fácil interactuar. También utilizamos Fitnesse internamente para las pruebas de integración, y encuentro que escribir los accesorios para Fitnesse mientras construyo mi Los objetos comerciales ayudan a mantener las cosas enfocadas en la perspectiva del usuario de la historia.

Debo decir, sin embargo, que terminas con un ciclo TDD bastante interesante cuando comienzas con una prueba de Fitnesse que falla, luego creas una Prueba de Unidad que falla para esa funcionalidad y vuelves a subir la pila. En algunos casos, también estoy escribiendo pruebas de unidad de base de datos, por lo que hay otra capa de pruebas que se pueden escribir, fallar y aprobar, antes de que se aprueben las pruebas de Fitnesse.

Answer 2

Si el cambio es probable, comience en el frente. Puede obtener retroalimentación inmediata de los accionistas. ¿Quién sabe? Tal vez en realidad no saben lo que quieren. Míralos usar la interfaz (IU, servicio u otro). Sus acciones pueden inspirarte a ver el problema bajo una nueva perspectiva. Si puede detectar los cambios antes de codificar los objetos del dominio y la base de datos, ahorrará un montón de tiempo.

Si los requisitos son rígidos, no es tan importante. Comience en la capa que probablemente sea la más difícil: aborde el riesgo temprano. En definitiva, este es uno de esos "más un arte que una ciencia". cuestiones. Probablemente sea una interacción delicada entre el diseño de capa que crea la mejor solución.

Saludos.

Answer 3

Lo haría de abajo hacia arriba, ya que obtendrá algunos resultados de trabajo rápidamente (es decir, puede escribir pruebas unitarias sin una interfaz de usuario, pero no puede probar la interfaz de usuario hasta que el modelo esté listo).

Sin embargo, hay otras opiniones.

Answer 4

Comenzaría a modelar el dominio del problema. Cree clases relevantes que representen las entidades del sistema. Una vez que me sienta seguro con eso, trataría de encontrar una asignación factible para persistir las entidades en la base de datos. Si pones demasiado trabajo en la interfaz de usuario antes de tener un modelo del dominio, existe un riesgo importante de que necesites volver a trabajar la interfaz de usuario más adelante.

Pensando en ello, probablemente necesites hacer algunas actualizaciones en todas las capas de todos modos ... =)