La separación de la lógica de negocio [cerrada]

Question

Cuando estaba optimización de mi arquitectura de nuestras aplicaciones en nuestro sitio web, que llegó a un problema que no sé la mejor solución para.

Ahora bien, en el momento en que tenemos una pequeña DLL basado en esta estructura:

Database <-> DAL <-> BLL 

Dal utiliza Business Objects para pasar a la BLL que pasará a las aplicaciones que utiliza este archivo DLL.

Sólo el BLL es público por lo que cualquier aplicación que incluye esta DLL, puede ver el BLL.

En un principio, esto era una buena solución para nuestra empresa. Pero cuando estamos añadiendo más y más aplicaciones en esa DLL, cuanto mayor sea el Böll está recibiendo. Ahora no queremos que algunas aplicaciones pueden ver BLL-lógica de otras aplicaciones.

Ahora no sé cuál es la mejor solución es para eso.

Lo primero que pensé fue, mover y separar el BLL a otros de DLL que puedo incluir en mi solicitud. Pero entonces es necesario que el Dal ser pública, por lo que los otros de DLL puede obtener los datos ... y que me parece una buena solución.

Mi otra solución, es sólo para separar el BLL en diferentes espacios de nombres, y basta con incluir solamente los espacios de nombres que necesita en las aplicaciones. Pero en esta solución, se puede obtener directamente el acceso a otra BLL es si lo desea.

Así que estoy pidiendo sus opiniones.

Answer 1

Estoy de acuerdo con @MikeC. Separar la BLL en espacios de nombres, para cada segmento. Además, separar el DAL también, como esto:

• MyCompany.HumanResources.DAL
• MyCompany.Insurance.DAL

Otra cosa que hacer, es separar de la DLL . De esta manera, usted no necesita hacer público DAL. Será una capa de negocio (como WCF o Web-servicio), responsables de BLL y DAL, para cada sistema, haciendo que el soporte y mantenimiento más fácil . No sé si es el enfoque más asequible para su empresa en este momento (en términos de complejidad), pero su un mejor enfoque para los propósitos Diseño .

veces antes, las aplicaciones desarrolladas aquí en la empresa, que se utiliza componente Architeture - compartir los componentes a través de aplicaciones -. Nos dimos cuenta de que, que no era el mejor diseño y en la actualidad, muchos sistemas (en el ambiente de producción) el uso que el enfoque de diseño.

Además: Si desea una mayor complejidad, también se podría generar un componente genérico dbHelper, responsable de mantener el acceso a los datos, incluidas las operaciones que controla las conexiones, comandos y transacciones. De esta manera, la prevención de la reescritura de código. Eso podría montaje hace uso de Enterprise Library u otros componentes. Un ejemplo de operación podría ser:

public DbCommand CreateCommand()
    {
        if (this._baseCommand.Transaction != null)
        {
            DbCommand command = this._baseConnection.CreateCommand();
            command.Transaction = this._baseCommand.Transaction;
            return command;
        }
        return this._baseConnection.CreateCommand();
    }

Puede que sea virtual, la implementación de un CreateCommand y SqlCommand así sucesivamente.

El recordar: la idea genérica dbHelper expuse, es sólo un idea

Answer 2

Se debe tener un BLL distinta y DAL para cada "segmento" de los negocios ... por ejemplo:

• MyCompany.HumanResources.BLL
• MyCompany.Insurance.BLL
• MyCompany.Accounting.BLL

Answer 3

Le sugiero que permite separar la lógica de negocio en diferentes DLL de acuerdo a su pertence (de acuerdo con el post anterior), estas clases implementarán interfaz específica, mientras que esta interfaz se declarará en que se conecte el negocio de consumo. Entonces le sugiero que permite implementar los contenedores (ver Inversión de Control teoría) para resolver DLL aplicación, esto le permite a la aplicación lógica de negocio separada de consumo y que será capaz de reemplazar algunos aplicación por otra, sin dificultad.

defiendo el uso de proveedor con la COI y no el consumo de las clases de dirigentes empresariales directamente (pensar en las referencias que pueden resultar en pesadilla). Esta solución resuelve el problema del aislamiento de DLL y su consumo optimizado.

Answer 4

Parece que usted tiene lógica común de negocios, que se aplica la organización en general, y la lógica más específica por cada sección o departamento. Se podría configurar su código de una manera para que cada departamento. sólo depende de su lógica específica, que detrás de las escenas utiliza ninguna funcionalidad genérica en la lógica "de base". A tal fin, se puede configurar los siguientes proyectos:

• Business.BLL
• Business.Finance.BLL
• Business.IT.BLL
• (etc, hasta el infinito, y así sucesivamente ...)

Tenga en cuenta que cada uno de ellos puede ser un proyecto independiente, que compila a su propia asamblea. sería sólo necesita un departamento para utilizar su propio montaje.

En lo que va de acceso a datos, puede tener acceso a datos genéricos rutinas en su BLL base. Sus BLLs específicos pueden tener sus propias consultas de datos especializadas que son canalizados a la BLL base, que a su vez utiliza los DAL genéricos y devuelve resultados respaldan la cadena.