c# - varios - rutas de acceso de referencia visual studio

Solución.NET-muchos proyectos vs un proyecto (10)

Actualmente tenemos una base de código C # en rápido crecimiento. Actualmente tenemos alrededor de 10 proyectos, divididos en las categorías habituales, cosas comunes / utilitarias, capa de red, base de datos, componentes / controles de la interfaz de usuario, etc.

Nos encontramos con la dependencia circular ocasional donde el proyecto x depende de algo en y y viceversa. Estamos considerando tal vez colapsar los proyectos en uno solo y solo administrarlos utilizando carpetas de estructura / espacios de nombres. Tenemos un proyecto Java que, por supuesto, organiza solo el uso de carpetas / paquetes, por lo que no estamos seguros de qué beneficio, si es que hay alguno, tiene múltiples proyectos. Ninguno de nuestros proyectos requiere propiedades especiales del proyecto, excepto el proyecto de ejecución principal, que podemos mantener separados (y muy delgados).

¿Alguien tiene experiencia previa en por qué un proyecto es mejor / peor que múltiples proyectos y podría sugerir el mejor enfoque? Y también cualquier problema con las dependencias circulares sería útil en cualquiera de los enfoques sería útil.

Cualquier entrada apreciada.

Comience con un solo proyecto. El único beneficio de dividir su base de código en más proyectos es simplemente mejorar el tiempo de compilación.

Cuando tenga alguna funcionalidad reutilizable que realmente quiero aislar del proyecto principal, simplemente comenzaré a usar una solución totalmente nueva.

Cuando se hacen dependencias entre proyectos, ayuda siempre pensar en uno como "Inferior" y el otro como "Superior"

Un proyecto de nivel superior (como una interfaz web) solo debe depender de proyectos inferiores. Un proyecto inferior (como una utilidad) nunca debe depender de algo superior, como una interfaz web. Si esto sucede, significa que su proyecto de nivel superior tiene algo que realmente debería estar en el proyecto inferior, o viceversa.

Donde trabajo, optamos por un enfoque donde el objetivo es tener un solo proyecto por solución. Todos los proyectos de biblioteca de códigos también tienen una aplicación de prueba de arnés y / o una aplicación de prueba de unidad.

Siempre que las bibliotecas de códigos pasen las pruebas, las versiones de lanzamiento (con el archivo de documentación Xml, por supuesto) se transfieren a una carpeta "En vivo".

Cualquier proyecto que requiera funcionalidad de estos otros proyectos debe hacer referencia a ellos desde la carpeta "En vivo".

Las ventajas son bastante claras. Cualquier proyecto siempre accede al código de trabajo conocido. Nunca hay una posibilidad de hacer referencia a una asamblea de trabajo en progreso. El código se prueba por ensamblaje, lo que hace que sea mucho más fácil comprender dónde se origina un error. Las soluciones más pequeñas son más fáciles de manejar.

¡Espero que esto ayude!

Sábalo

En general, tener varios proyectos de VS (dentro de una solución de VS) solo tiene sentido en estos casos

Puede reutilizar la DLL producida en otro proyecto (una biblioteca de clases)
Desea separar cosas como en una arquitectura en capas en la que puede soltar la dll DAO y cambiarla por otra
Solo hay diferentes proyectos de front-end (es decir, aplicaciones ASP.net MVC) que deben implementarse en diferentes ubicaciones físicas pero usan el mismo BL, DAL.

Si dice que tiene el problema de las dependencias circulares, entonces tiene un problema en el diseño de su código. Probablemente puede poner esa lógica que es utilizada por múltiples proyectos dentro de una biblioteca de clases diseñada para ser reutilizada en muchos proyectos.

En general, yo diría que no debe agregar más proyectos si realmente no lo necesita. Dividirse en proyectos significa agregar más complejidad, por lo que cuando lo haga, debería obtener un beneficio razonable de ello.

En mi experiencia, el código de separación que crea un único ejecutable en varios proyectos puede ser útil si desea

utilizar diferentes lenguajes de programación en diferentes partes,
Desarrollar bibliotecas que también son utilizadas por otras aplicaciones, o
conceptualmente separe las capas múltiples (es decir, permita que Visual Studio se asegure de que no haya referencias directas del proyecto Lib al proyecto de la aplicación ).

Personalmente, baso la mayoría de mis decisiones en el segundo punto. ¿Pienso que parte de la aplicación puede ser una biblioteca más general que es probable que necesite en otra aplicación? Ponlo en un proyecto separado. De lo contrario, como señala, tener un solo proyecto generalmente facilita el desarrollo.

Acerca de las dependencias circulares: la forma recomendada de resolver esto es colocar interfaces de los elementos a los que se hace referencia en un tercer proyecto. Por ejemplo, si tiene dos aplicaciones que comparten algunos objetos a través de la comunicación remota, coloque interfaces de los objetos compartidos en un proyecto de biblioteca para asegurarse de que estén disponibles para ambas aplicaciones.

Sin conocer el diseño exacto de su aplicación, es difícil dar consejos más concretos.

Hay varias razones para separar una solución en diferentes proyectos (y, por lo tanto, en ensamblajes), y principalmente se trata de la reutilización y la separación de responsabilidades .

Ahora su objetivo debe ser hacer que un ensamblaje (proyecto aka) tenga la cantidad mínima de dependencias en otros ensamblajes en su solución, de lo contrario, también puede tener todo en menos ensamblajes. Si, por ejemplo, sus componentes de UI tienen una fuerte dependencia de su código de acceso a datos, entonces probablemente haya algo mal.

Realmente, esto se reduce a la programación contra interfaces comunes.

Nota Sin embargo:

Cuando digo "de lo contrario, es mejor que tengas todo en menos ensamblajes", no estaba necesariamente sugiriendo que esto es algo incorrecto. Para lograr una verdadera separación de preocupaciones, usted estará escribiendo mucho más código y tendrá que pensar mucho más en su diseño. Es posible que todo este trabajo adicional no sea muy beneficioso para usted, así que piénselo bien.

Hemos notado que el rendimiento de Visual Studio se degrada significativamente a medida que aumenta la cantidad de proyectos. Algo tan simple como cambiar las configuraciones de ''Depurar'' a ''Liberar'' puede llevar hasta 15 segundos a soluciones con una docena de proyectos de C # en ellas.

Además, como un punto contrario al comentario de Reed sobre los tiempos de compilación, he visto crecer los tiempos de compilación porque Visual Studio parece estar gastando mucho tiempo en la sobrecarga del proyecto. Los tiempos de compilación reales parecen rápidos, pero el tiempo total desde que se ejecutó el compilado hasta que se ejecutó es significativo.

Mi consejo sería mantener el número de proyectos al mínimo que pueda realizar. Si necesita varios proyectos por buenas razones, entonces utilícelos según sea necesario, pero prefiera mantener las cosas juntas. También puede refactorizar para dividir un proyecto en dos si es necesario.

Múltiples proyectos permite una mejor reutilización de tipos específicos dentro de múltiples aplicaciones. También puede mejorar el tiempo de compilación, ya que no será necesario reconstruir ciertos proyectos para todos los cambios de código.

Un solo proyecto facilita la vida, ya que no tiene que preocuparse por las dependencias. Solo tenga en cuenta que la facilidad tiene un costo: también hace que sea más fácil dejar que las malas decisiones de diseño se introduzcan en la base del código. Las dependencias circulares, ya sea en un proyecto o en múltiples, son típicamente un defecto de diseño, no un requisito.

Si tiene proyectos con dependencias circulares, eso indica un problema con el diseño del código, no con el modelo de solución / proyecto.

Es posible que el siguiente artículo de Martin valga la pena: Principios de diseño y patrones de diseño (PDF) (Java) .

Una versión revisada en C # está específicamente disponible en Principios, patrones y prácticas ágiles en C # también por Martin.

Ambos expresan diferentes pautas que te ayudarán a decidir a qué pertenece dónde. Sin embargo, como se señaló, las dependencias cíclicas indican que hay problemas con el diseño o que algo está en un componente que pertenece a uno diferente.