Tengo una solución para mi aplicación web con casi 12 proyectos y 3 sitios web. Hay algunos proyectos que uso para varios sitios web como MyProject.BE/MyProject.BLL/MyProject.DAL/MyProject.Controls projects.Visual Studio Solución grande
Mi pregunta es, ¿es bueno tener múltiples proyectos para BE/BLL/DAL/Controls, de ¿es mejor crear 1 proyecto con carpetas para las capas BE/BLL/DAL?
La cuestión de "grande" es relativa. En el desarrollo de software, es principalmente una cuestión de qué tan bueno es tu PC. Si puede compilar y ejecutar 100 proyectos en 1 segundo, entonces 100 proyectos en una solución son "pequeños". Entonces, realmente es una cuestión de lo que funciona para usted.
Mi solución de trabajo actual tiene alrededor de 130 proyectos en ella. Sí, podríamos resolverlo, pero tenemos algunas cajas impresionantes que pueden manejar esto, por lo que el costo de tener 130 proyectos es de moderado a bajo y las ventajas son mayores que los costos.
Tener todos los proyectos en una sola solución es ir si puede compilar, ejecutar, & probarlos todos rápidamente. Maldición ... eso luego inicia la conversación en lo que es "rápido" y esa es una pregunta de estilo. Si compila y ejecuta pruebas a menudo (cada minuto o más rápido), entonces rápido es segundos. Si compila y ejecuta cada hora más o menos, los minutos estarían bien.
Respuesta: "Haz lo que funcione para ti".
Nota: Considere las carpetas de soluciones.
Mi última compañía tenía más de 350 proyectos en una sola solución. La mayoría de los proyectos eran bibliotecas de clase a las que se hacía referencia en otro proyecto. Aunque la solución tenía 350 proyectos, esto no significa que se tratara de una gran solución. Era una solución grande debido a la complejidad y cantidad de código que tenía cada proyecto. Como dijo Rob Smyth, todo es relativo. Descubrimos que construir toda la solución era peligroso, por lo que solo creamos los proyectos que teníamos que hacer. ES DECIR. solo creamos los proyectos en los que habíamos realizado cambios. – zeencat
+1 para ayudar a determinar qué solución "grande" podría ser, también +1 para la sugerencia de uso de la carpeta. – Larry
por "buena PC" ¿está hablando principalmente de RAM (tamaño y velocidad)? o es la velocidad de acceso a la unidad de disco duro más importante? – mlhDev
Creo que es mejor tener varios proyectos. Si, por ejemplo, necesita construir una interfaz de usuario de WinForms que use algunas de las clases existentes en sus capas BE y DAL, todo lo que necesita hacer es referenciar esos proyectos desde el proyecto WinForms.
Por lo que respecta a la respuesta a su pregunta, se refiere a cómo organizar una solución en lugar de cómo hacer la compilación del código más rápido o cómo hacerlo VS- abre mi código más rápido, ¿verdad?
Si es así, yo diría que se dividen las clases dentro de la solución en varios proyectos con nombres que dejan claro el propósito que tienen. Ya comenzó un enfoque como ese con el ejemplo "BE/BLL/DAL/Controls" que dio.
Tener un proyecto designado le da mucha flexibilidad para la arquitectura de su solución. Piense en cuánto puede crecer su solución con el tiempo y durante cuánto tiempo puede vivir en el futuro. Piense cómo implementarlo en los usuarios finales y, lo que es más importante, cómo implementará las actualizaciones. Todas estas consideraciones deben influir en su decisión hasta dónde llegará en detalles.
Analice su código y verifique si existe la posibilidad de aplicar patrones de diseño probados por el tiempo, como el patrón de responsabilidad única.
¿Es una herramienta efímera a corto plazo que se ejecuta varias veces durante el desarrollo y nunca más? Entonces no valdría mucho esfuerzo. ¿Es una herramienta o aplicación que deberá mantenerse unos años? Luego ve y haz que el patrón de SRP se implemente cuidadosamente.
recomiendo este libro de Microsoft Press: Building Enterprise Applications with Windows Presentation Foundation and the Model View ViewModel Pattern
Esto le da algunas sugerencias, recomendaciones y conceptos básicos de cómo construir una buena estructura del proyecto.
Otra sugerencia de cómo una solución podría ser estructurado es en este SO hilo: Mvvm Applications And location of Business layer
Si ellos se funden en uno, ¿cómo se va a hacer referencia a ella en otros, el actual parece bien, pero es que el actual problema/problema? – V4Vendetta
* casi 12 proyectos * - es decir, 11 proyectos? –
Múltiples proyectos está perfectamente bien. He trabajado en soluciones con ~ 60 proyectos. –