División de capas de aplicación en diferentes conjuntos

Question

Hay un debate en curso en mi empresa. Algunos defienden el movimiento de entidades empresariales, de datos y comerciales en un solo ensamblaje para

• Finalidad de la detección. haga que sea más fácil encontrar lo que está buscando.
• Reducir el número de DLL tenemos que añadir a un proyecto para el desarrollo

Otros citan la guía de arquitectura de la aplicación que desee cada capa y las entidades de negocio en un ensamblado independiente.

Tenga en cuenta que

• Nuestros capas de negocio y datos tanto constan de componentes COM +.
• Nuestra arquitectura de hardware actual tiene web, negocios y datos en la misma caja.
• SQL en una caja diferente.
• Actualmente no usamos el control de versiones dll porque, en general, es inútil con com + de todos modos.

Algunos de nosotros tenemos la corazonada de que deberíamos dividir nuestro negocio, los datos y las entidades, pero son pocos los motivos.

• reducir potencialmente el consumo de memoria
• Fomentar la arquitectura adecuada sólo tienen conjuntos de capas de negocio añadido a los proyectos web. Si los servicios de datos también están disponibles, entonces es más fácil hacer las cosas de la manera incorrecta
• Cuando dividimos nuestro servidor web de las capas comerciales y de datos, no tendremos que instalar basura que no necesitamos de un ensamblaje de Dios .

Ahora mismo tenemos unos 600 dll en nuestro sistema. Entonces estamos en un extremo donde todo está dividido. Definitivamente hay algo de consolidación que puede suceder, pero lo que se propone es llevarnos a otro extremo completo donde cada aplicación está en una dll.

¿Podría obtener alguna perspectiva externa sobre este problema común?

Gracias!

Answer 1

DLL o ensamblados son unidades de distribución.

1. Si el código en un espacio de nombre o clase particular está tan estrechamente vinculado con otro espacio de nombres o clase, entonces debe estar en la misma unidad de distribución. Si el código en el archivo foo. * Nunca se utilizará sin necesidad del código en la barra. * Archivo, entonces también puede compilarlos en la misma unidad de distribución.
2. Si un espacio de nombre o grupo de clases representa un componente reutilizable (es decir, ese código se utiliza en dos o más productos/aplicaciones), entonces es un buen candidato para ser versionado por separado y ser su propia unidad de distribución.

Para mí, se trata principalmente de la cohesión, el acoplamiento y la reutilización.
Me gusta que las clases en una unidad particular de distribución sean cohesivas, no me gusta el acoplamiento entre unidades de distribución (casi preferiría que haya dependencias en una tercera unidad de distribución que contenga interfaces tales que el acoplamiento se realice a través de dependencias en abstracciones en lugar de concreciones). La reutilización es la clave para mí al tomar decisiones sobre las unidades de distribución. Si el código va a ser utilizado en múltiples aplicaciones/productos, entonces debe ser una unidad de distribución separada con su propio número de versión que es independiente del número de versión de la aplicación.

Answer 2

El objetivo de nuestro equipo es tener el menor número posible de ensamblajes. Además de los beneficios que enumera, también he descubierto que es más fácil lidiar con las pesadillas de versión de DLL cuando hay una menor cantidad de DLL. El uso de un número excesivo de ensamblajes también presenta el riesgo de crear referencias circulares entre ensamblajes.

No salimos de nuestro camino para meter el código en un ensamblaje al que no pertenece. Pero definitivamente no creamos un nuevo ensamblaje sin una razón sólida para hacerlo. Por lo general, tenemos un ensamblaje para la lógica compartida de la aplicación (objetos comerciales, etc.) y un ensamblaje para la interfaz de usuario (el ensamblaje web, el ensamblaje WinForms, etc.). Tampoco duplicamos código/clases entre ensamblajes solo para evitar la creación de un nuevo ensamblaje.

Answer 3

Dividir en los límites de despliegue físico es una buena idea. Si tiene componentes que pueden hospedarse para uso remoto, entonces un ensamblaje separado tiene sentido. Esa es probablemente la línea más fácil y sólida para dividir, para empezar. Hay pocos casos en los que desee el nivel web para incluir los servicios comerciales y el código de acceso a datos, por ejemplo.

A partir de ahí, intente reducir los ensamblajes a las cosas que tienen sentido para la versión de forma independiente. Si siempre tiene que copiar más de 10 ensamblajes juntos, entonces probablemente deberían compilarse como uno solo.