¿Cuál es el número óptimo de proyectos en una solución de Visual Studio 2008?

Question

¿Cuál es el número óptimo de proyectos en una solución de Visual Studio 2008?

Tenemos una solución de Visual Studio 2008 que tiene alrededor de 50 proyectos en este momento. Es probable que continúe creciendo ya que la mayoría de los proyectos dentro de la solución consisten en conjuntos de complementos para la aplicación principal.

Si parece que hay demasiados proyectos en una solución, ¿cómo determinaría qué proyectos deberían agruparse en una solución? Dado nuestro ejemplo de aproximadamente 50 proyectos en una sola solución, con la mayoría de los proyectos como complementos y con la cantidad de complementos que probablemente crecerán, ¿cómo deberían estructurarse las soluciones? ¿Deberían colocarse todos los complementos en su propia solución? ¿Cómo debe cambiar la organización cuando la cantidad de complementos en la solución de complementos alcanza el número mágico de "demasiados"?

No tenemos ningún problema con tantos proyectos en la solución ... se carga rápidamente, se construye rápidamente, usa una cantidad de memoria razonable y no provoca que el VS2008 se estrelle o choque con ningún VS2008 errores.

He buscado la documentación de Microsoft (no parece que haya ninguna) y las búsquedas de Google recomendaciones de "cada proyecto tiene su propia solución" para "colocar todos los proyectos en una sola solución". Ambos extremos parecen ser absurdos. Estoy buscando alguna guía razonable en el medio.

Ha habido otras preguntas sobre Stackoverflow relacionadas con el maximum que ha visto. Eso no es lo mismo que lo que sería óptimo.

Answer 1

Esto es similar a discusiones como "¿cuántas funciones debo tener en una clase?" y "¿debería definirse cada enumeración en su propio archivo .cs?".

Me gustaría saber cuántas clases tiene cada uno de sus proyectos. Puedes pensar en tus clases, proyectos y soluciones como unidades organizativas. Están ahí para facilitarle la vida y para permitirle a usted (y a su equipo) dividir el proyecto en trozos conceptuales manejables.

Si VS2008 no se queja, y usted y sus desarrolladores no tienen ningún problema con 50 proyectos en una solución, entonces no me preocuparía.

Dicho esto, suena como un número bastante grande, pero no sabemos nada sobre el tamaño de la base de código general, por lo que es difícil comentar más.

Answer 2

Yo diría que necesita al menos 1 proyecto para cada capa en su sistema. Si necesita más proyectos, tal vez sea un problema de diseño. Lo que significa que puedes diseñar "Sobre" o "Debajo" diseñar la aplicación.

I nowdas utilizar las siguientes capas:

DataLayer - responsable de la estructura de datos subyacente (la base de datos). En los últimos casos teniendo el LINQ y clases parciales para esto en este proyecto.

Interfaces - Tener una capa para todas las interfaces, esto para ayudar a ampliar y no tener que depender de algunas otras capas para usar estas interfaces.

Lógica - Este sí, la lógica de negocio

GUI/Frente define - La interfaz gráfica de usuario (Código)

Estas capas son las otras capas mínimos que podrían ser posibles serían Localización y otro proyecto que podría crecer

¡Pero simplifique a directorios y espacios de nombres que a muchos proyectos!

Answer 3

Obviamente, cuando llega a 500, está empezando a ver "demasiados", que se vuelve poco práctico incluso para administrarlo.

Le sugiero que analice "lo que realmente constituye mi aplicación" y que lo incluya como una solución única. Los complementos raramente se consideran parte de la aplicación base, sino complementos de la funcionalidad base.

Si la aplicación dejaría de ser útil sin ciertos complementos, inclúyalos en la solución base.

Otros complementos se pueden agrupar en Género ... al igual que las listas de reproducción en su iPod. ¿Qué logra cada complemento en un nivel más general? (Estas son obviamente preguntas retóricas) Agruparía los complementos en grupos naturales, al igual que los complementos de PhotoShop a medida que se agrupan en el menú. es decir, si afectan a 3D, si afectan el color, si afectan los efectos geométricos, si afectan a la distorsión, etc.

Answer 4

Cuando veo una desaceleración, tiendo a crear una solución que tenga referencias a versiones compuestas (ensambles) de proyectos dependientes en lugar de a archivos de proyecto (para proyectos que no necesitan ver el código fuente) . Solo abro la fuente para los proyectos en los que estoy trabajando: seguramente nadie necesita trabajar en la fuente de 50 proyectos a la vez.

Si ya hace referencia a los ensamblajes dependientes en lugar de a la fuente, entonces creo que es solo una cuestión o preferencia organizativa (organícese de una forma que sea más fácil para usted comprender y mantener).