Separação da lógica de negócios [fechado

Question

Quando eu estava otimizando minha arquitetura de nossos aplicativos em nosso site, cheguei a um problema para o qual não conheço a melhor solução.

Agora, no momento, temos uma pequena DLL com base nessa estrutura:

Database <-> DAL <-> BLL 

O DAL usa objetos de negócios para passar para o BLL que o passará para os aplicativos que usam essa DLL.

Somente o BLL é público; portanto, qualquer aplicativo que inclua essa DLL possa ver o BLL.

No começo, essa foi uma boa solução para a nossa empresa. Mas quando estamos adicionando cada vez mais aplicativos nessa DLL, quanto maior o BLL está obtendo. Agora não queremos que alguns aplicativos possam ver o BLL-Logic de outros aplicativos.

Agora não sei qual é a melhor solução para isso.

A primeira coisa que pensei foi: Mover e separar o BLL para outras DLLs que posso incluir no meu aplicativo. Mas então o dal deve ser público, para que as outras DLLs possam obter os dados ... e que eu pareço uma boa solução.

Minha outra solução é apenas separar o BLL em diferentes namespaces e apenas incluir apenas os espaços para nome que você precisa nos aplicativos. Mas nesta solução, você pode obter acesso diretamente a outros BLL's, se quiser.

Então, estou pedindo suas opiniões.

Answer 1

Eu concordo com @mikec. Separe o BLL em namespaces, para cada segmento. Além disso, separe o dal também, assim:

• Mycompany.humanResources.dal
• Mycompany.insurance.dal

Outra coisa a fazer é Separe o DLL's. Dessa forma, você não precisa tornar o dal público. Será uma camada de negócios (como WCF ou Web Service), responsável por BLL e DAL, para cada sistema, fazendo o Suporte e manutenção mais fáceis. Não sei se é a abordagem mais acessível para sua empresa agora (em termos de complexidade), mas é uma abordagem melhor para fins de design.

Times antes, os aplicativos desenvolvidos aqui na empresa, usavam arquitetura de componentes - Compartilhando os componentes. -. Percebemos que, não era o melhor design e, hoje, muitos sistemas (na produção de produção) usam essa abordagem de design.

Além disso: se você deseja mais complexidade, também pode gerar um componente DBHelper genérico, responsável por manter o acesso aos dados, incluindo operações que controlam as conexões, comandos e transações. Assim, impedindo o reescrever de código. Essa assembléia poderia fazer uso de Biblioteca Enterprise ou outros componentes. Um exemplo de operação pode 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();
    }

Você pode torná -lo virtual, implementando um SQLCommand CreateCommand e assim por diante.

Lembrando: a ideia genérica de dbhelper que eu expus é apenas um idéia!

Answer 2

Você deve ter um BLL e DAL distinto para cada "segmento" dos negócios ... por exemplo:

• Mycompany.humanResources.bll
• Mycompany.insurance.bll
• MyCompany.COccounting.bll

Answer 3

Sugiro que você separe sua lógica de negócios em diferentes DLLs de acordo com a pertência deles (de acordo com a postagem anterior), essas classes implementarão interface específica enquanto essa interface será declarada no seu consumidor de login de negócios. Depois, sugiro que você implemente os contêineres (consulte a inversão da teoria do controle) para resolver a implementação da DLL, isso permitirá separar a implementação da lógica de negócios do consumo e você poderá substituir alguma implementação por outro, sem dificuldade.

Eu defendo o uso do provedor com o COI e não o consumo de classes de gerente de negócios diretamente (pense em referências que podem resultar em pesadelo). Esta solução resolve o problema do isolamento da DLL e seu consumo otimizado.

Answer 4

Parece que você tem uma lógica de negócios comum, que aplica a sua organização em geral e uma lógica mais específica por seção ou departamento. Você pode configurar seu código de uma maneira para que cada departamento. Depende apenas de sua lógica específica, que nos bastidores usa qualquer funcionalidade genérica na lógica "base". Para esse fim, você pode configurar os seguintes projetos:

• Business.bll
• Business.finance.bll
• Business.it.bll
• (etc, ad infinitum, e assim por diante ...)

Observe que cada um deles pode ser um projeto separado, que compila com sua própria montagem. Um departamento só precisaria usar sua própria assembléia.

No que diz respeito ao acesso aos dados, você pode ter rotinas genéricas de acesso a dados em seu BLL base. Seus BLLs específicos podem ter suas próprias consultas de dados especializadas que são canalizadas para a base BLL, que por sua vez usa o DAL genérico e retorna os resultados de backup da corrente.