1. Inicio
  2. Pregunta y respuesta
  3. Mejor práctica al crear espacio de nombres corporativo reutilizable

Mejor práctica al crear espacio de nombres corporativo reutilizable

2011-09-25 9 views
6

Bien, esto ha estado en mi mente por un tiempo. Estoy en el proceso de crear un espacio de nombres corporativo reutilizable (biblioteca de clases) para todos los objetos comunes de nivel medio. Este ensamblaje puede ser referenciado por cualquiera de nuestros desarrolladores durante la fase de desarrollo de su proyecto. Aquí está mi pregunta ¿Es más aceptable crear un ensamblaje único que consista en toda nuestra lógica de nivel medio o dividir esta funcionalidad en ensamblajes más pequeños?Mejor práctica al crear espacio de nombres corporativo reutilizable

Ejemplo: Asamblea Individual (ejemplos de espacio de nombres)

sistema

System.IO

System.IO.RegEx

System.Net

System.Net. Correo

System.security

System.Web - AssemblyFull.dll

Ejemplo: varios ensamblados

System.IO

System.IO.Reg - se compila a AssemblyIO.dll

System.Net

System.Net - compila a AssemblyNet.dll

En el pasado he hecho esto con ambos métodos, pero me pregunto lo que todos hacen y por qué? No estoy buscando ningún ejemplo de código, solo quiero saber lo que otros desarrolladores están haciendo.

Gracias de antemano.

Fuente

2011-09-25 TCNS-Bob

+0

¿Qué tan grande sería el montaje sea si sólo contenía todo? ¿Espera que los proyectos de su empresa utilicen todas las funcionalidades comunes? Si no, ¿puede separarlo lógicamente en subunidades relacionadas (que podrían ser buenos candidatos para organizar diferentes ensamblajes)? –

+0

google para el principio de equivalencia de reutilización/liberación – driushkin

+0

Richard - El ensamblaje [completo] estará compuesto por cientos de objetos. La mayoría de los proyectos siempre usarán entre el 75% y el 85% de la funcionalidad expuesta, pero también podrían usar otras piezas. Mi pensamiento inicial fue manejar esto tal como lo dijiste. Tome los objetos más utilizados y construya en un conjunto común, luego tome los otros objetos y divídalos en unidades separadas. Pero, por otro lado, puedo ver cómo un solo ensamblaje podría facilitar la vida de otros desarrolladores. Solo necesitaría hacer referencia al ensamblaje de nivel medio y terminarlo. Tengo la sensación de que esto es 6 a 1 media docena al otro –

Respuesta

4

Como regla general, utilizo para separar ensamblajes si no están acoplados explícitamente. Por ejemplo, si tiene una API de redes de bajo nivel y otra API para operaciones relacionadas con FTP, probablemente la última dependa de la anterior; pero para el usuario API, sus desarrolladores; no es necesario tener ambos en un solo ensamblaje; tal vez un proyecto no requiera FTP API, por lo que solo deben incluir el ensamblado "Net" central. Puede separar las API para que sean lo más atómicas posible y evitar que los desarrolladores incluyan un ensamblaje grande cuando utilicen solo una pequeña parte.

El inconveniente de este enfoque es que si el desarrollador necesita el ensamblado de FTP, también deben incluir el de red; por lo que debe encontrar una forma de administrar esas dependencias que reduzca la complejidad de los desarrolladores. Yo uso Maven (from Apache) cuando hago aplicaciones Java pero para esta fecha no conozco un buen maven-like alternative for .NET.

Pero si está creando algunas API para su empresa, con un sitio Wiki u otra herramienta de documentación de peso ligero puede solucionar este problema.

Fuente

2011-09-25 17:47:05

+0

Lorenzo - gracias por la respuesta rápida. Es la primera vez que escucho hablar de Maven, suena genial. Cuanto más pienso sobre esto, romper mis objetos tiene más sentido. Bien separándolos tanto como sea posible. Si uno de los desarrolladores necesita acceso a la funcionalidad de correo electrónico, realmente no hay ninguna razón para que los objetos de criptografía sean visibles/accesibles. Gracias por todas las respuestas rápidas chicos, realmente aprecio recibir aportes de otros. Además, veo que no soy el único que trabaja los domingos. –

+0

@lorenzo NuGet (www.nuget.org) es lo más cerca que vas a llegar a Maven en .NET – x0n

+0

Tks @xOn, voy a evalúo Nuget ... –

1

No creo que sea una respuesta correcta para esto, pero tiendo a utilizar un enfoque de nomenclatura común para todas nuestras bibliotecas.

Tengo una biblioteca que maneja gran parte de la funcionalidad de nivel medio, algo así como las tareas comunes que usarían la mayoría de las aplicaciones.

Web.CreditCard
Web.CreditCard.Authorization
Web.CreditCard.Charge
Web.CreditCard.Batch

Web.Store.Order
Web.Store.Entities
Web.Store. cesta
Web.Store.Auth

Web.User.Auth.OpenID
Web.User.Auth.OAuth
Web.User.Account
Web.User.Preferences

Por lo tanto, no importa qué tipo de proyecto de su edificio se puede volver a utilizarlos e identificarlos muy rápido. Algunos de ellos tienen sus propias interfaces y pueden ser heredados y sobrecargados para agregar más funcionalidad dependiendo de los requisitos del proyecto.

Fuente

2011-09-25 18:07:21

+0

Esto es casi exactamente lo que estoy viendo en nuestro repositorio. Solo quería que sea lo más fácil posible para otros desarrolladores. Voy a seguir adelante con un ensamblado común que se utilizará para todos los proyectos y luego ensamblajes separados para una funcionalidad no tan común. Gracias a todos los que me respondieron tan rápido, realmente lo aprecio. –

0

Gracias a todos los que respondieron a esta pregunta. Como cada proyecto es diferente y es casi imposible encontrar una respuesta correcta, describiré cómo abordaré esto.

Primero:

necesito para identificar qué negocio/objetos de nivel medio van a ser utilizados en todos los proyectos que se mueven hacia adelante. Una vez que estos han sido identificados Voy a crear un montaje [empresa] .common o [empresa] .common.util. Estos serán referenciados para cada uno de nuestros proyectos actuales y futuros.

Segundo:

identificar los objetos que son más proyecto específico. Estas asambleas pueden o no estar referenciadas. Un ejemplo sería [empresa] .security.cryptography.

Tercero:

Asegúrese de que cada objeto está bien documentado para que los futuros desarrolladores tendrán los conocimientos necesarios para mantener adecuadamente y hacer referencia a los conjuntos correctos.

Quería agradecer a todos por responderme tan rápido. Esta fue mi primera publicación en SO, pero puedo asegurarte que me verás aquí de nuevo muy pronto. Gracias de nuevo.

Fuente

2011-09-26 15:44:48

+1

Por mi parte, no me gusta usar el nombre de la compañía dentro de un espacio de nombres, solía trabajar con Verizon y muchos espacios de nombres donde Verizon.[Nombre] y ahora ese pedazo de la compañía ya no se llama Verizon, pero aún tiene ese espacio de nombres pegado allí. –

+0

Punto válido. Normalmente utilizo el nombre de la compañía debido al hecho de que generalmente realizamos alguna forma de integración en la que es más fácil identificar de dónde vino el ensamblaje. Si estuviera creando un espacio de nombre genérico, ¿qué usaría como su nivel superior? –

0

Utilicé un enfoque diferente para los archivos reutilizables.

puedo crear una solución separada que incluye todos los componentes reutilizables, etc. probar

Cada "cosa" reutilizable (clase, función, control de usuario, icono, etc.) se encuentra en un archivo separado.

Los proyectos que necesitan algunas funciones de la parte reutilizable simplemente enlazar directamente con el archivo de origen. ("Agregar elemento existente", "Agregar como enlace"). Para mayor comodidad coloco todas las piezas reutilizadas en una carpeta "Utilidades" en VS (la carpeta utilidades reales está vacía ya que los archivos están vinculados)

Esta configuración me permite:

  • sólo tiene que añadir la funcionalidad que común necesitará
  • sin dependencias adicionales
  • Corrección de errores en las utilidades se incluyen automáticamente en el próximo acumulación

El único inconveniente es que si necesita manualmente para añadir cualquier depe ndencies se obtuvo la funcionalidad añadida (p. otro componente reutilizable o un conjunto)

Ya que no utilizan diferentes conjuntos, el espacio de nombres se limita a seguir la función:

  • Company.Utilites
  • Company.Utilites.WPF
  • Company.Utilites .IO

Fuente

2011-09-26 16:08:04 adrianm

Cuestiones relacionadas

 Cuestiones relacionadas