Carpetas o proyectos en una solución de Visual Studio?

Question

Al dividir una solución en capas lógicas, ¿cuándo es mejor usar un proyecto separado sobre simplemente agrupar por una carpeta?

Answer 1

Por defecto, siempre a crear nueva carpeta dentro del mismo proyecto

• Usted recibirá solo conjunto (sin gimnástica ILMerge adicional)
• más fácil para ofuscar (ya que tendrá tipos menos comunes y métodos, idealmente ninguno en absoluto)

La separación de su código fuente en múltiples proyectos sólo tiene sentido si ...

• tienen algunas porciones del código fuente que forman parte del proyecto, pero no se despliegue de manera predeterminada o en absoluto (pruebas unitarias, plugins extra, etc.)
• más desarrolladores involucrados y que desea tratar su trabajo como consumible negro caja. (no muy recomendado)
• Si puede separar claramente su proyecto en capas/módulos aislados y quiere asegurarse de que no pueden consumir miembros internos miembros.(tampoco se recomienda porque tendrá que decidir qué aspecto es el más importante)

Si cree que algunas partes de su código fuente podrían ser reutilizables, aún así no las cree como un proyecto nuevo. Simplemente espere hasta que realmente desee reutilizarlo en otra solución y aislarlo del proyecto original según sea necesario. La programación no es un lego, la reutilización suele ser muy difícil y, a menudo, no ocurrirá según lo planeado.

Answer 2

Normalmente hago un proyecto para la GUI, un proyecto para la lógica de negocios, un proyecto para acceso a datos y un proyecto para pruebas unitarias.

Pero a veces es prudente tener separación basada en servicios (si está utilizando una arquitectura orientada a servicios) como autenticación, ventas, etc.

supongo que la regla de oro que yo trabajo fuera de que es si puede verlo como un componente que tiene una clara separación de preocupaciones, entonces un proyecto diferente podría ser prudente. Pero creo que las carpetas versus los proyectos podrían ser solo una preferencia o filosofía.

Personalmente creo que si el código reutilizable se divide en proyectos, es más sencillo usar otros lugares que si solo estuviera en carpetas.

Answer 3

Denny escribió:

Personalmente, creo que si el código reutilizable se divide en proyectos es más fácil de usar que otros lugares si es sólo en carpetas.

Estoy realmente de acuerdo con esto, si puedes reutilizarlo, debería ser en un proyecto separado. Dicho esto, también es muy difícil volver a utilizar con eficacia :)

Aquí en SO, hemos tratado de ser muy simple con tres proyectos:

• proyecto Web MVC (que hace un buen trabajo de separar sus capas en carpetas por defecto) proyecto
• base de datos para el control de la fuente de nuestra base de datos
• las pruebas unitarias contra modelos MVC/controladores

no puedo hablar por todos, pero estoy feliz w ¡Cuán simple lo hemos mantenido, realmente acelera las construcciones!

Answer 4

La separación de su código fuente en múltiples proyectos sólo tiene sentido si se ... ... Más desarrolladores involucrados y quiere tratar su trabajo como cuadro negro consumible. (no se recomienda muy ) ...

¿Por qué no se recomienda esto? Encontré que es una forma muy útil de administrar una aplicación con varios desarrolladores trabajando en diferentes porciones. Hace que checkins sea mucho más fácil, principalmente al eliminar virtualmente las fusiones. Muy rara vez dos desarrolladores tendrán que trabajar en el mismo proyecto al mismo tiempo.

Answer 5

Separar las características en los proyectos suele ser una optimización de la arquitectura YAGNI. ¿Con qué frecuencia ha reutilizado esos proyectos separados realmente? Si no es una ocurrencia frecuente, está complicando su desarrollo, construcción, despliegue y mantenimiento para su reutilización teórica.

Prefiero separarme en carpetas (usando los espacios de nombres apropiados) y refactorizar para separar proyectos cuando tenga un caso de uso de reutilización de la vida real.

Answer 6

Si va a crear varios proyectos, asegúrese de que todos los que agreguen el código a la solución tengan plena conciencia de la intención de ellos y hagan todo lo posible para que comprendan las dependencias entre los proyectos. Si alguna vez ha tratado de resolver el problema cuando alguien se ha ido y ha agregado referencias que no deberían haber estado allí y se salieron con la suya durante semanas, comprenderá este punto

Answer 7

Realmente creo que es mejor dividir el proyecto también, pero todo depende del tamaño del proyecto y del número de personas que trabajan en él.

Para proyectos más grandes, que tienen un proyectos para

• acceso a datos (modelos)
• servicios
• frontales
• pruebas

que obtuve el modelo de Rob Connery y su aplicación de escaparate ... parece funcionar muy bien.

mvc-storefront