La mejor manera de hacer frente a negocio fusionado y el código de presentación?

Question

Teniendo en cuenta una situación hipotética en la que una biblioteca de presentación de edad, el legado se ha mantenido a lo largo de los años, y ha tenido poco a poco cada vez más la lógica de negocio codificado en él a través de un proceso de correcciones precipitadas y la falta de supervisión arquitectónica adecuada. Como alternativa, considere una clase de negocios o espacio de nombres que no está separado de la presentación por los límites de montaje, por lo que era capaz de hacer referencia a algo así como System.Windows.Forms sin estar obligado a añadir una referencia (una acción mucho más aleccionador que una cláusula simple usando) .

En situaciones como ésta, no es inimaginable que el código de negocio utilizado por el código de interfaz de usuario con el tiempo será llamado para su reutilización. ¿Qué es una buena manera de refactorizar las dos capas de separación para permitir esto?

Soy vagamente familiarizado con los patrones de diseño - al menos en principio, de todos modos. Sin embargo, no tengo toda una tonelada de experiencia práctica, así que estoy un poco inseguro de mis intuiciones. He empezado a lo largo de la ruta de utilizar el patrón Estrategia para esto. La idea es identificar los lugares donde la lógica de negocio llama a componentes de interfaz para preguntar al usuario una pregunta y recopilar datos, y luego para encapsular los en un conjunto de interfaces. Cada método en dicha interfaz contendrá el código orientado UI-del flujo de trabajo original, y la clase de interfaz de usuario a continuación, poner en práctica esa interfaz.

El nuevo código que quiere reutilizar la lógica de negocio en cuestión también será implementar esta interfaz, pero sustituir las ventanas, ya sea nuevos o posiblemente respuestas prefabricadas o parametrizados a las preguntas contestadas originalmente por los componentes de interfaz de usuario. De esta manera, la lógica de negocio puede ser tratada como una biblioteca real, aunque con un parámetro de la interfaz algo torpe pasado a algunos de sus métodos.

¿Es este un enfoque decente? ¿Qué mejor debería ir sobre esto? Voy a ceder ante su sabiduría colectiva de Internet.

Gracias!

Answer 1

parece estar tomando un enfoque bien, en el que se rompe dependencias entre elementos de hormigón en su diseño a la vez dependerá de abstracciones (interfaces). Cuando se rompe dependencias de esta manera, usted debe comenzar inmediatamente el uso de pruebas de unidad para cubrir su base de código heredado y evolucionar el diseño con la mejora de la seguridad.

He encontrado el libro trabajo efectivo con Código legado a ser muy valiosa en estas situaciones. Además, no entrar de lleno en los patrones sin antes mirar a los principios de diseño orientado a objetos, como la SÓLIDO principios . A menudo se guían su elección de los patrones y las decisiones acerca de la evolución del sistema.

Answer 2

Humildemente sugiero Modelo-Vista -Controller - MVC tiene una alta probabilidad de éxito como una solución a su problema. Se separa la lógica diversos, tanto como usted describe.

HTH

Answer 3

Me acercarse a ella por identificar claramente las entidades y las acciones que pueden hacer o se puede hacer para ellos. Luego, uno por uno intenta iniciar la creación de objetos independientes de lógica de negocio para aquellos refactorización la lógica de la interfaz de usuario, la interfaz de usuario que realiza la llamada a la BL objetos.

En ese momento si entiendo su escenario correctamente, tendría una mano llena de BL objetos, una parte de lo que hizo ganar formas llamadas, necesitarían las formas de ganar llamadas a ser promovido a cabo en la capa de interfaz de usuario.

A continuación, como dice JustBoo, ??yo creo que tengas una situación bastante distinta a la abstracción de comenzar a cabo los controladores de su BL y la interfaz de usuario y hacer que todas las funciones en un diseño MVC.

Answer 4

Está bien, teniendo en cuenta sus diversos comentarios, me gustaría seguir el consejo del señor Hoffa y extenderlo. Estoy seguro que has oído problemas difíciles deben ser divididas en unidades cada vez más pequeñas de trabajo hasta que puedan ser "conquistados".

Uso de que la técnica, junto con las metodologías de Refactoring podría resolver sus problemas. Hay un libro y una gran cantidad de información en la web sobre el tema. Ahora tiene un enlace. Esa página tiene un montón de enlaces a la información.

Un eslabón más de la href="http://www.refactoring.com/" rel="nofollow noreferrer"> del libro.

Por lo tanto, refactoriza, poco a poco a la bondad cremosa de MVC, paso a paso.

HTH