Buenas prácticas en soluciones de Visual Studio [cerrado]

Esperemos que sea una pregunta simple de relatividad. Estoy empezando a trabajar en un nuevo proyecto interno para crear capacidad de rastreo de dispositivos reparados dentro de los edificios.

La base de datos se almacena de forma remota en un servidor web, y se accederá a través de la API web (salida JSON) y se protegerá con OAuth. La interfaz gráfica de usuario de front-end se realiza en WPF y el código comercial en C #.

A partir de esto, veo las diferentes capas Presentación / Aplicación / Almacén de datos. Habrá un código para administrar todas las llamadas autenticadas a la API, una clase para representar entidades (objetos comerciales), clases para construir las entidades (objetos comerciales), partes para la GUI de WPF, partes de los modelos de vista de WPF, etc.

¿Es mejor crear esto en un solo proyecto, o dividirlos en proyectos individuales?

En mi corazón digo que debería ser múltiples proyectos. Lo he hecho en ambos sentidos anteriormente, y descubrí que las pruebas son más fáciles con una sola solución de proyecto, sin embargo, con múltiples proyectos, pueden surgir dependencias recursivas. Especialmente cuando las clases tienen interfaces para facilitar la prueba, he descubierto que las cosas pueden volverse incómodas.

Depende del tamaño del proyecto.

Aquí están las pautas que suelo usar

• Un proyecto pequeño, con un puñado de páginas o menos, casi siempre mantengo un solo proyecto.

• Si la capa de acceso a datos del proyecto pequeño es grande o compleja, podría separarla en su propia capa, pero de lo contrario simplemente se ubica en su propia carpeta.

• Si el proyecto es más grande, casi siempre tendré un proyecto separado para el DAL, y cualquier división adicional dependerá de dónde se encuentran los límites entre la funcionalidad de la aplicación.

• Si la aplicación tiene múltiples propósitos, cada uno con sus propias vistas, modelos de vista, etc., generalmente separaré cada pieza en su propia área. Si cada sección es pequeña, las separo por una carpeta. Si cada sección es grande, las separaré por un proyecto.

• Si tengo varios proyectos que necesitan para hacer referencia al mismo conjunto de objetos ( ViewModelBase, RelayCommand, etc), voy a crear un proyecto sólo para los objetos de infraestructura compartida.

• Si tengo una gran cantidad de estilos / plantillas / recursos personalizados compartidos, crearé un proyecto solo para esos.

Como nota al margen, cometí un error con mi primer gran proyecto WPF y los separé poniendo Modelos en un proyecto, Vistas en otro y ViewModels en un tercero. Te puedo decir que ese no es el camino a seguir, ya que el mantenimiento se convierte en una pesadilla :)

He visto los mejores resultados con un proyecto por capa, más un proyecto de prueba por capa. He visto pocas aplicaciones que no se pueden lograr en 10 o menos proyectos en la solución, donde la solución lo abarca todo .

No caigas en la trampa de usar proyectos donde realmente quieres espacios de nombres. Toneladas de proyectos no agrega nada más que gastos generales sin ganancia.

En mi humilde opinión, casi siempre es mejor. Casi siempre separo mi capa de datos a menos que el proyecto sea 100% trivial. La razón es porque la capa de datos tiende a pasar más a menudo. Raramente conectará una GUI a múltiples capas de datos y esperará que funcione bien. El escenario mucho más común es que tiene una sola capa de datos y desea que se distribuya entre múltiples GUI (ASP.Net, WPF y una aplicación Silverlight, por ejemplo). Es increíble cuando puedes construir el proyecto de capa de datos y poner ese dll como referencia en la próxima GUI que construyas.

Para mí, 4 * es el número mágico. Un proyecto para cada capa y un proyecto que define todas las interfaces / DTO necesarios para comunicarse entre ellos.

* 7 si cuentas las pruebas unitarias

Siempre he usado una única solución si estoy trabajando en esas capas diferentes, o si hay un acoplamiento estrecho con ellas. Quiero llegar a F5 y hacer que todos los proyectos se reconstruyan si es necesario. No creo que haya una forma "correcta" de hacerlo.

Su gusto personal, lo más importante es ser consistente . Personalmente, tengo un proyecto separado para cada capa de la aplicación, por lo que la separación es obvia.

El aumento en el número de proyectos tiene que ver con habilitar las pruebas unitarias y simplificar el gráfico de dependencia hasta el punto en que las cosas no son tan complejas que los cambios en una parte de la aplicación rompen las cosas en partes aparentemente no relacionadas de la aplicación.

Funciona cuando estoy haciendo algún tipo de inversión de dependencia, para poner todos los "contratos", interfaces, clases abstractas, objetos de transferencia de datos en un solo ensamblaje. En otra asamblea puse todo lo que habla a la base de datos. Las pruebas unitarias obtienen su propio ensamblaje. Si la interfaz de usuario es fundamentalmente no comprobable (por ejemplo, Win.NET ASP.NET), entonces hay un beneficio significativo al dividir la interfaz de usuario en código comprobable y código no comprobable, un ensamblaje cada uno. A veces, comienza a aparecer un código que no tiene nada que ver con la base de datos, la interfaz de usuario o cualquier cosa que haya mencionado hasta ahora; es un código que deseaba que estuviera en el marco .NET. Ese código lo pondré en un conjunto de utilidades, o al menos lo pondré en el conjunto raíz (probablemente el que tiene las interfaces.

Si todos los ensamblajes hacen referencia a todos los ensamblajes, o casi, entonces deberían fusionarse nuevamente en un ensamblaje único. Si usted o las personas de su equipo carecen de la disciplina para evitar colocar el código del nivel de datos en la interfaz de usuario y la interfaz de usuario en el nivel de datos, entonces simplifique las cosas fusionando todo en una sola capa.

Algunas ediciones de Visual Studio se encuentran con problemas de rendimiento en aproximadamente 15 ensamblados, a veces depende de qué tipo de proyecto hay. Sin embargo, la descarga estratégica de archivos de proyecto a veces puede ayudar.

La única buena razón para tener más de un proyecto es si necesita compartir un conjunto de clases y archivos en múltiples aplicaciones.

Si los proyectos son utilizados por una sola aplicación, no deberían haberse realizado en primer lugar. Use espacios de nombres en su lugar. Ahórrese el problema de las referencias circulares, la sobrecarga de dll y la confusión del proyecto al buscar archivos.

Lea este artículo para obtener una explicación más detallada de por qué es así: http://lostechies.com/chadmyers/2008/07/16/project-anti-pattern-many-projects-in-a-visual-studio- archivo-solución /

Y como dice el artículo, agradecería a cualquiera que tenga una razón válida para tener múltiples proyectos, aparte del código compartido en la aplicación, que me diga qué es, porque dudo que haya alguno.