¿Cuál es la forma óptima de organizar un proyecto de C#?

Question

Me preguntaba cómo organizan sus proyectos, en términos de funcionalidad, alcance, etc.

¿Tiene un proyecto para pruebas de unidad, un proyecto para código de biblioteca de clase, un proyecto para interfaz de usuario?

¿O acabas de dividir todo esto en carpetas separadas?

Estaba pensando que separarlos por proyectos es más fácil, porque la biblioteca de códigos centrales está en un solo lugar, sin referencias directas a UserInterface (sin dependencias de WinForms) o UnitTests.

¿Alguna opinión?

Answer 1

Intento dividir proyectos en lo que podría llamar "unidades de despliegue". En otras palabras, "¿Cómo podría implementar estas asambleas?"

Porque obviamente no estoy implementando pruebas unitarias, están en su propio proyecto.

Luego, divido la IU y la "lógica comercial" en proyectos separados. Si mantengo estas líneas de separación limpias, puedo reemplazar mi capa de interfaz de usuario con una nueva tecnología o infraestructura (piense en WPF frente a ASP.NET) y aún reutilizar los ensamblados de "lógica de negocios" para ambos. Acabo de presentar una nueva capa de interfaz de usuario que comprende la interfaz de lógica de negocios.

También trato de mantener una biblioteca separada para el código que podría compartir entre las soluciones. Esta sería mi utilidad de acceso a datos, utilidades de análisis de archivos y otras que uso una y otra vez a medida que construyo proyectos. Puedo simplemente incluir esos ensambles en mis nuevas soluciones y obtengo toda esa funcionalidad en la que ya he invertido mi tiempo.

Espero que ayude.

Answer 2

Realice algunas búsquedas en Stack Overflow y en Google; hay otras personas que hicieron la misma pregunta.

Algunas consideraciones:

Visual Studio necesita más tiempo para compilar soluciones con muchos proyectos, que los grandes proyectos individuales. No divida su solución demasiado finamente.

Microsoft Composite Application Guidance tiene una forma interesante de dividir proyectos. Hay un proyecto de Infraestructura, un proyecto de arranque y luego proyectos para cada "módulo" de código.

Actualmente estoy trabajando en un proyecto que divide los proyectos como su ejemplo: infraestructura, lógica de negocios, GUI y pruebas unitarias.

Prefiero organizar archivos por propósito, no por tipo. Por ejemplo, creo carpetas llamadas "Comunicación" e "Interoperabilidad" en lugar de "Eventos" e "Interfaces".

Answer 3

¿Tiene un proyecto para la unidad pruebas, un proyecto de biblioteca de clases de código , un proyecto para la interfaz de usuario?

Bastante esto. Por lo general, mantenga la IU esbelta y mueva cualquier lógica comercial a su propio (s) proyecto (s), con un proyecto de prueba por proyecto de lógica de negocios.

Answer 4

Rompo proyectos por tipo de ensamblaje como usted describió. Es bueno tener al menos el proyecto principal que es ejecutable (si es una aplicación) y una o más bibliotecas de clase. Si es una aplicación de Windows, definitivamente intente separar la IU del código tanto como sea posible. Las aplicaciones de WPF hacen un trabajo maravilloso al lograr eso.

Aparte de eso, algunos otros consejos que podría prestar es, definitivamente, recopilar algunas bibliotecas de clases de terceros y escribir algunas propias cuando la reutilización del código sea obvia o aparente.

Answer 5

últimos pocos proyectos que he estado involucrado en - Terminamos con la siguiente estructura (Todos los proyectos WPF Prism):

xxx.Shell.Exe

xxx.yyyModule.dll (x 4- 7)

xxx.Tests

xxx.Model

xxx.Common

Y para aquellos que usan WCF - añadir:

xxx.Backend

xxx.DataContracts

Solución todo en uno (vivimos con las largas acumulaciones veces ...) dividiéndola en las soluciones separadas introdujeron demasiados problemas al refactorizar. Hasta ahora, ha funcionado muy bien para nosotros.

Answer 6

Unos patrones que he encontrado útiles en la organización de proyectos dentro de una solución:

casi siempre tienen una o proyecto "común" "utilidades". Este proyecto debe tener muy pocas dependencias, por lo que se puede reutilizar fácilmente en cualquier lugar y en cualquier lugar de mi solución (o posiblemente en otras soluciones). Te sorprenderás de cuántas clases pequeñas de ayuda se incluirán en este proyecto.

Siempre trato de separar mi lógica empresarial en un proyecto (o más probablemente un conjunto de proyectos), y mi código de arranque/proveedor en un proyecto diferente (o conjunto de proyectos). Mis clases bootstrap/provider son específicas del contexto (pueden asumir la presencia de un HttpContext o args de línea de comandos, etc.), pero no contienen lógica comercial. Mis clases de negocios implementan la lógica de negocios, pero no asumen la presencia o ausencia de elementos específicos del contexto. De esta forma, si inicialmente construyo el sistema como una aplicación de consola, más adelante puedo escribir un conjunto de bootstrap/proveedores de servicio de Windows y transformarlo rápidamente en un servicio de Windows con un impacto mínimo o nulo en las clases de negocios.

Similar a las clases de bootstrap/proveedor, también trato de aislar mi capa de datos de mis clases de negocios. Pero esa es una separación común y básica que todos han escuchado 1000 veces, por lo que apenas vale la pena mencionarla.

La lógica de negocios de muchos sistemas es demasiado compleja para encajar en un solo proyecto y mantener un grado de mantenibilidad del código. Por lo tanto, generalmente me encuentro con múltiples proyectos de lógica de negocios, agrupados por área funcional ("gestión de clientes", "inventario de productos", etc.).

Answer 7

que algo como esto en términos de proyectos dentro de una solución:

Administración - Documentación general, copia maestra de licencia, etc. por lo general va también hacen de esta compilación de una pequeña línea de comandos "readme "aplicación que muestra la licencia, notas de revisión, etc.

Datos: datos generales, como XML, etc. No hay código compilable.

Biblioteca1 ... BibliotecaN - Una o más bibliotecas (generalmente 1-3: utils, core, extended code).

Aplicación1 ... AplicaciónN - Aplicación (normalmente una).

Prueba1 ... TestN - Pruebas.

Dentro de cada proyecto, guardo los archivos para cada espacio de nombres en carpetas separadas, espacios de sub-archivos en subcarpetas, etc. Guardo tipos comunes de cosas, como documentación, biblioteca o datos específicos de la aplicación, texto de licencia incorporado, etc., en subcarpetas con el mismo nombre, independientemente del proyecto.

-Neil

Answer 8

Si estás haciendo una aplicación de negocio ish con una interfaz de usuario, usted debe buscar en MVC.

Por supuesto, MVC es solo un concepto general, pero es uno que te ayuda a tomar decisiones del tipo que estás enfrentando en este momento.

Hay muchos recursos en MVC en WPF, que probablemente también pueda aplicar directamente a WinForms.