Cómo refactorizar grandes proyectos en visual studio

Question

Siempre me tropiezo con un problema donde mis proyectos en Visual Studio (2008) se vuelven enormes monstruosidades y todo generalmente se lanza a un proyecto de aplicación web. Sé que al revisar algunas cosas de código abierto tienden a tener múltiples proyectos dentro de una solución, cada uno con sus propias responsabilidades.

¿Alguien tiene algún consejo para cómo refactorizar esto? ¿Qué debería ser en un proyecto separado vs. parte del proyecto web? ¿Puede indicarme algún material de referencia sobre el tema, o es algo a lo que se acostumbre con el tiempo?

Answer 1

Organice su proyecto limpiamente en espacios de nombres. Los espacios de nombres no deben ser demasiado grandes ni demasiado pequeños. Haga que cada espacio de nombre tenga una "interfaz" pública (es decir, un conjunto de clases públicas) y no acceda a los detalles de implementación interna del espacio de nombres desde otros espacios de nombres. Los diferentes espacios de nombres generalmente abordan diferentes partes de una aplicación, p. tendrá espacios de nombres relacionados con la interfaz de usuario, lógica de negocios, funcionalidad de ayudante, etc. El Framework Design Guidelines tiene algunas buenas sugerencias sobre cómo diseñar espacios de nombres.

Cuando sienta que su proyecto crece demasiado, simplemente identifique conjuntos de espacios de nombres que estén claramente relacionados entre sí y muévalos a proyectos separados. Como otros espacios de nombres ya usan la interfaz pública de los espacios de nombres movidos, la refacturación de los espacios de nombres en nuevos proyectos es simplemente una operación de traslado de archivos.

Answer 2

Comience de abajo hacia arriba (sus clases más simples que no dependen de nada más que el Framework) y vea si puede aislar las dependencias en unidades funcionales. Por ejemplo, si tiene un montón de datos o clases de lógica de negocios que se referencian entre sí, pero nunca hace referencia a ninguna de sus clases de interfaz de usuario, entonces tiene un candidato para dividirse en otro proyecto. Si no puede encontrar puntos de separación claros, entonces tiene un problema de diseño y probablemente deba hacer una refactorización.

También estoy de acuerdo que el uso de espacios de nombres es un buen lugar para comenzar. Incluso dentro de un proyecto, a menudo puede aislar o minimizar las dependencias de una manera que naturalmente agrupa las clases juntas. Ponerlos en la misma carpeta refuerza esta agrupación como una unidad funcional y puede ayudar realmente al pobre tipo que debe mantener su código en el futuro. Créeme, trato de pensar en ese pobre tipo porque, en más de una ocasión, ese pobre hombre fui yo. Fue un pequeño consuelo que la persona que escribió el código tuviera el mismo nombre que yo en el momento en que lo escribió.

Answer 3

Mira la guidance given by the Sharp Architecture project. Es ASP.Net MVC, pero los mismos principios se aplican a ASP.NET y otros proyectos. Los chicos que juntan esto son smart Por lo general, utilizo sus consejos como el predeterminado y solo me pierdo cuando tengo un buen motivo.

La organización en niveles básico que ellos proponen es

• Un proyecto núcleo para sus objetos de dominio e interfaces para acceder a los servicios externos (incluyendo persistencia).
• A datos proyecto que depende de núcleo e implementa todas las interfaces para el acceso a la persistencia
• Un servicios de aplicaciones proyecto de apoyo preocupaciones a nivel de aplicación tales como el registro o la validación de inicio de sesión. Esto solo hace referencia al núcleo.
• Un web proyecto que tiene sólo puntos de vista.
• A controladores proyecto que contiene su código de arranque y el código para coordinar su capa web, dominio.

En el caso de una aplicación asp.net me gusta usar el patrón MVP lo que básicamente significa que el proyecto

• Web mantiene sus formularios Web y codebehinds que debe contener sólo la cantidad mínima de código requerido para redirigir al presentador. Probablemente también necesites poner tu código de arranque allí. Esto se debe a una limitación de ASP.Net y NO debes hacer referencia a ninguna de esas cosas desde tus códigos subyacentes.
• Controladores El proyecto se reemplazó por un proyecto de presentadores. La gran diferencia aquí es que de alguna manera el presentador tiene que ser instanciado por el WebForm en lugar de al revés.

También puede intentar comprobar el ASP.NET MVP project.