Bucketing de clase. .
https://stackoverflow.com/questions/312565
-
10-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Ok, entonces he estado tratando de poner a todos una de mis clases en alguna carpeta raíz, ya sea:
UI
BusinessLogic
DataAccess
BusinessObjects
Interfaces
Tengo algunas más en las que parece que no puedo moverme muy bien, así que estoy buscando sugerencias
-
Una clase de caché que mantiene un diccionario privado y permite un acceso diferente a los objetos en función de algunas teclas específicas
-
¿Clases de evento Arg?
Además, en un proyecto ahora empiezo a tener subsistemas que tienen los 3 (acceso a datos, objetos comerciales, busiensslogic). ¿Cómo debo dividir la estructura de carpetas?
A.
ProjectX
--Subsistema1
---- BusinessObjects
---- DataAccess
---- BusinessObjects
--Subsistema2
---- BusinessObjects
---- DataAccess
---- BusinessObjects
o
ProjectX
--BusienssLogic
---- Subsistema1BL
---- Subsistema2BL
--DataAccess
---- Subsistema1DA
---- Subsistema 2DA
--Objetos de negocios
---- Subsistema1BO
---- Subsistema2BO
o
ProjectX
--BusinessLogic
--DataAccess
--Objetos de negocios
(sin subdirectorios para cada subsistema funcional)
Solución
Intento alinear los nombres de mis ensamblajes con sus espacios de nombres, y utilizo .NET Framework como guía. Creo firmemente que trabajar con una estructura de espacio de nombres que impulsa una estructura de carpetas crea una base de código mucho más fácil de mantener.
Por ejemplo, tengo un proveedor de almacenamiento en caché que forma parte del marco de desarrollo global que utilizamos. Vive en un espacio de nombres de algo similar a:
[Empresa] .Core.Data.Caching
Tengo otra funcionalidad relacionada con los datos que lógicamente también se encuentra debajo de la función Datos, por lo que el almacenamiento en caché tiene hermanos como Adaptadores, Convertidores y Generadores. Entonces, supongamos que tenemos los siguientes espacios de nombres:
[Empresa] .Core.Data.Adapters
[Empresa] .Core.Data.Converters
[Empresa] .Core.Data.Caching
[Empresa] .Core.Data.Generators
Estos espacios de nombres relacionados viven en un ensamblado llamado [Compañía] .Core.Data, que también es el nombre del proyecto. Encontrar cosas en la solución se vuelve muy simple siguiendo esta estructura. Hablando de estructura, ahora volvemos a cómo se almacenan en el disco.
El nombre del proyecto es el nombre de la carpeta raíz. Esto asume mi carpeta de control de origen, que es "C: \ Control de origen" en mi máquina local:
C: \ Source Control \ Core [Compañía] .Core.Data \
C: \ Source Control \ Core [Compañía] .Core.Data \ Adapters
C: \ Source Control \ Core [Compañía] .Core.Data \ Caching
C: \ Source Control \ Core [Compañía] .Core.Data \ Converters
C: \ Source Control \ Core [Compañía] .Core.Data \ Generadores
Entonces, como jerarquía, se ve algo así como:
[Solución]
- [Empresa] .Core.Data
---- [Adaptadores]
------ (Archivos de adaptadores)
---- [Almacenamiento en caché]
------ (Almacenamiento en caché de archivos)
---- [Convertidores]
------ (Archivos convertidores)
Puse todos los proyectos al mismo nivel y varío los subespacios de nombres con las carpetas. De esta forma, los espacios de nombres y las estructuras físicas son fáciles de conciliar. La parte difícil es encontrar el equilibrio. No desea tener una gran cantidad de ensamblajes más pequeños, por lo que normalmente los agruparé en un nivel más alto y eventualmente los refactorizaré cuando tenga tendencia a crecer demasiado, o si los espacios de subnombres cambian con más frecuencia que otras partes .
He estado haciendo esto durante años, y es muy cómodo no solo para mí, sino para que lo usen mis desarrolladores.
En cuanto a su pregunta EventArgs, estoy de acuerdo con el consenso de que normalmente hago una clase por archivo, pero haré la excepción de colocar una clase EventArgs con otra clase si es un uso singular. Para usos múltiples, los puse en el punto lógico más alto del ensamblaje, permitiendo que la estructura del espacio de nombres vincule mi alcance.
Otros consejos
Generalmente me gusta apegarme a la regla de 1 clase, 1 archivo, pero cuando se trata de EventArgs, en realidad me gusta declararlos en el mismo archivo que defino el delegado o evento. A menos que los argumentos sean utilizados por más de una jerarquía de clases, lo que no suele sucederme a menudo.
En cuanto a la caché, pondría en la carpeta de las clases en las que es compatible.
Por mucho que me guste la buena organización, uno puede ser demasiado anal con ella.
Esto es principalmente un gusto personal.
Estoy de acuerdo con lo que Brian Genisio dijo sobre dónde colocar las clases EventArg, etc .: si solo úselos una vez, póngalos en el mismo archivo donde los usa. Para las clases / archivos generales, siempre tengo una carpeta 'General' (¡qué conveniente! ;-))
Con respecto a la estructura de carpetas: iría con la segunda, esa es de 3 niveles Y mantiene los subsistemas separados. ¡Ganar-ganar!
Solo quiero agregar un comentario sobre los nombres. Siento que la palabra negocio lleva al mal uso. Hicimos esto, y ahora no sabemos de qué se trata: lógica de dominio o capa de servicio. Sugeriría nombres como Dominio. Domain.Impl (para separar las interfaces de Impl) y luego Servicios ... y quizás Persistencia si está usando ORM ... puede ser diferente si usa un enfoque diferente, pero para ser honesto, estoy confundido acerca de los nombres BusinessLogic, DataAccess y BusinessObjects. No entiendo qué es qué. BusinessObjects debe contener lógica empresarial, lógica? ¿O son solo DTO? Entonces, ¿por qué están en un proyecto separado de DataAccess?
