programa - Espacios de nombres y estructuras de carpetas en soluciones c#: ¿cómo deben organizarse las carpetas en el disco?

organizar archivos y carpetas procedimiento convencional (7)

"Primero, aceptemos que el espacio de nombres debe coincidir con la estructura de la carpeta y que cada artefacto de lenguaje [sic] debe estar en su propio archivo".

Es curioso, así es como funcionan los paquetes en Java. Siempre pensé que romper el vínculo entre espacios de nombres y estructura de directorios se consideraba una de las mejoras que C # introdujo. ¿Eso no es verdad? (Perdonen mi ignorancia, soy una persona de Java).

En primer lugar, aceptemos que el espacio de nombres debe coincidir con la estructura de la carpeta y que cada artefacto de lenguaje debe estar en su propio archivo.

(Consulte ¿Las carpetas en una solución deben coincidir con el espacio de nombres? ).

La siguiente pregunta es cómo las carpetas deberían estar organizadas en el disco.
Supongamos que tengo ClassC en el espacio de nombres ABC y ClassD en el espacio de nombres ABCD.
Supongamos también que cada espacio de nombres está integrado en su propio ensamblaje (proyecto) y que los espacios de nombres tienen dependencias de derecha a izquierda según las mejores prácticas aceptadas (ABCD puede depender de ABC que puede depender de AB que puede depender de A). Aprecio que cada espacio de nombres no tenga que estar en un ensamble separado, pero en el caso general tendremos algunos espacios de nombres en ensamblajes separados y mi ejemplo lo ilustra.

Puedo ver (al menos) dos formas de crear el árbol de carpetas, que llamaré "carpetas anidadas" y "carpetas planas":

1 - Carpetas anidadas:

UN
--A.csproj
--SEGUNDO
---- ABcsproj
----DO
------ ABCcsproj
------ classC.cs
------RE
-------- ABCDcsproj
-------- classD.cs

2 - Carpetas planas:

UN
--A.csproj
AB
--ABcsproj
A B C
--ABCcsproj
--classC.cs
A B C D
--ABCDcsproj
--classD.cs

Verás que ya hice algunas suposiciones:

Cada archivo de proyecto tiene un nombre completamente calificado (FQN) basado en el espacio de nombres.
Cada archivo de clase utiliza un no FQN

Las carpetas anidadas parecen más naturales (a todos nos gustan las jerarquías), pero puede ser un poco más difícil navegar en soluciones grandes:

Cuando mira su solución en VS, muestra una lista plana de proyectos en lugar de una vista anidada. Esto se parece más a "carpetas planas", por lo que puede ser útil organizar las carpetas en el disco para que coincidan con la vista en VS.

Si busca en cada carpeta del disco, verá los artefactos de la carpeta para ese proyecto más la subcarpeta del espacio de nombres: tomando C como ejemplo:

do
--compartimiento
--RE
--obj
--Propiedades
--ABCcsproj
--classC.cs

Dependiendo del nombre real de D, puede no ser obvio que D es una carpeta de espacio de nombres en lugar de una carpeta de organización en el espacio de nombres de C.

Sé que hemos tenido carpetas y espacios de nombres desde el primer día en .NET (hace 8 o 9 años) y Java antes de eso, pero, hablando personalmente, no parece que hayamos llegado a un consenso sobre la organización de proyectos de mejores prácticas para grandes soluciones. Estaría realmente interesado en descubrir lo que todos piensan.

Gracias
Miguel

No soy un gran admirador de los proyectos anidados, ya que entierra proyectos dentro de una estructura y si necesita reutilizar ese proyecto en otra aplicación, entonces, ¿qué hace usted para copiar y pegar el código? Me gusta seguir una estructura plana pero organizada por espacio de nombres.

Así es como lo hago:

- DataHelpers/ ---Factory/ ---DataAccess/ ---... - Components/ --- EmailProcessor/ --- ErrorLogger/ - Desktop/ --- WindowsApp1/ - Services/ --- WindowsService1/ --- WindowsService2/ - WebApps/ --- WebApp1/ --- WebApp2/

Ahora, dentro de cada aplicación principal que tengo, por ejemplo:

- WindowsService1/ --- WindowsService1/ (this contains all *.cs, bin, obj, etc and .csproj file) --- Solution/ (this contains the .sln file where you link to other projects like ErrorLogger, etc)

¡Espero que tenga sentido!

Siempre he hecho la jerarquía anidada. Hace dolorosamente obvio dónde agregar nuevos proyectos a una solución existente y mantiene sus espacios de nombres muy bien organizados en el disco. También hace que la delincuencia del espacio de nombres frente al proyecto sea más obvia.

Creo que necesitas definir un punto de corte donde el enfoque plano ya no funcione. Por ejemplo, si tiene una arquitectura típica de 3 niveles en un proyecto pequeño, tener 3 proyectos en el nivel externo no es un problema. Sin embargo, si tiene algunas docenas, entonces algún tipo de agrupación ayuda a segmentar la funcionalidad y hace que toda la solución sea más comprensible.

Yo uso el enfoque plano. Encuentro una jerarquía anidada demasiado difícil de mantener. Agrupe mis proyectos en varias soluciones, con máxima reutilización y referencias cruzadas en mente, y siempre me pareció satisfactorio. Ejemplo (los proyectos están sangrados):

CompanyName CompanyName.Core Class1 Struct2 Enum3 CompanyName.Data CompanyName.Web CompanyName.Projects CompanyName.Projects.Core CompanyName.Projects.ProjectX CompanyName.Projects.ProjectX.Core CompanyName.Projects.ProjectX.Website CompanyName.Projects.ProjectX.ToolY

etcétera etcétera.

Editar: comentario sin sentido eliminado

Si utiliza los proyectos anidados, corre el riesgo de acceder al problema MaxPath de Windows. Este es un gran factor decisivo para el uso de estructuras anidadas. Imagínese encontrarse con esta pequeña Gem a medio camino a través de un proyecto de desarrollo, teniendo que nombrar proyectos VS con acrónimos de 3 letras solo para no golpear a MaxPath. Un error de MS termina siendo la inspiración para los nombres de sus ensamblajes. Qué broma sería esa. Trabajar con estructuras planas es mucho mejor en general.

-SouceControlFolderName -Project1 -Src -Main -Company.Project1.AppName *Company.Project1.AppName.sln *Company.Project1.AppName.Tests.sln -Company.Project1.AppName.Common -Company.Project1.AppName.Common.Tests -Company.Project1.AppName.Entities -Company.Project1.AppName.Entities.Tests -Company.Project1.AppName.Security -Company.Project1.AppName.Security.Tests -etc.

Puede crear un directorio separado para los proyectos de prueba o como arriba y tenerlos todos juntos, que es más fácil de administrar cuando se agrega al control de fuente, es decir, Subversion (TFS es mejor en muchos aspectos excepto por el hecho de que necesita integración de Explorer y no solo integración de VS una historia fuera de línea adecuada)

Prefiero una estructura plana con proyectos en la raíz.

MyCorp.Core
MyApp.Domain
MyApp.Data
MyApp.UI
MyApp.Test

Dentro de estos tengo varias carpetas y espacios de nombres. Solo creo diferentes ensambles para unidades desplegables. Las pequeñas aplicaciones ni siquiera tendrán esta cantidad de separación. OMI esto mantiene las cosas simples. Si alguna vez decido que el código que tengo necesita ser utilizado en otro lugar, es bastante fácil dividirlo en un ensamblado si es necesario, siempre y cuando haya seguido buenas prácticas de creación de espacios de nombres.