Para que serve uma camada de lógica comercial (BLL)?

Ao ler as boas práticas para aplicativos de banco de dados, encontrei frequentemente defensores das chamadas "camadas da lógica de negócios" e estou tentando decidir se é melhor para o meu projeto usar um (é um pequeno projeto pessoal). Meu problema está no fato de que não consigo pensar em nada para o BLL fazer com que o DAL já não possa lidar (executando consultas e mapeando resultados para objetos); portanto, meu BLL chama o DAL sem fazer nada sozinho.

Talvez eu esteja errado sobre o que o DAL também deveria estar fazendo. Mas, independentemente disso, que tipo de funcionalidade deve ser esperado de uma BLL em um aplicativo de gerenciamento de banco de dados?

Para meus aplicativos menores, minha BLL geralmente inicia como uma passagem para o DAL. Eu estou bem com isso. À medida que "descubro" as regras de negócios, a BLL é onde as coloco. Também acabo encontrando muitas coisas necessárias no BLL enquanto escrevo meus testes. Para meus próprios aplicativos pessoais, eu componho as regras de negócios, e o BLL ainda é onde eu as coloco. Para mim, o BLL é algo que cresce com o tempo. Quanto mais eu trabalhei em um projeto, maior o seu BLL.

Consideraria combinar o BLL e o DAL para um projeto pequeno? Eu posso, exceto pelo fato de alterar as tecnologias DAL com a mesma frequência com que altero os penteados, e gosto de ter algo para isolar meu código de cliente disso.

O BLL trataria de coisas que fazem parte do domínio comercial, não fazem parte do banco de dados e não fazem parte da interface do usuário (normalmente). Por exemplo, usando a idade de um cliente para determinar se ele se qualifica para um desconto especial para idosos. O DAL não deveria estar fazendo isso, deveria simplesmente recuperar os dados do cliente e, em seguida, armazená-lo com os dados de desconto após o BLL concluir seu trabalho. O DAL deve se concentrar mais em CRUD. Em pequenas aplicações, as duas preocupações podem se sobrepor.

Andrew,

Camadas de lógica de negócios é o que você cria quando desenvolve o desenvolvimento dirigido por domínio e se concentra nas atividades principais do domínio. Se você remover a camada de apresentação (GUI, Web) e a camada de infra-estrutura (banco de dados, conectividade de rede etc.), terá as principais atividades que fazem parte do seu domínio, como depositar dinheiro em uma conta bancária. Agora, se você modelou sua camada de negócios e a isolou da apresentação e da infra-estrutura, é possível portá-la facilmente para outros usos, como dispositivos móveis ou da Web. É uma maneira limpa de pensar sobre desenvolvimento e, pelo que vi, não é levado tão a sério, infelizmente.

Eu recomendo que você ponha as mãos em Eric Evans - Design Orientado a Domínio, que é um bom livro que justifica concentrar os esforços de desenvolvimento no domínio. É certo que é uma leitura meio seca, mas ganha força e tem algumas convicções fortes sobre o que os desenvolvedores estão fazendo de errado com os sistemas atuais.

Não há nada que diga que você precisa ter um certo número de camadas ou camadas. Tudo depende da complexidade do seu projeto. Dê uma olhada em muitos dos aplicativos de amostra do MVC, como jantar nerd ou loja de discos. Todos eles usam duas camadas porque, para aplicativos que têm muito pouca lógica de processamento, isso simplesmente não faz sentido.

No entanto, mesmo que seu aplicativo seja pequeno, ele poderá se beneficiar da abstração da camada de dados da camada de apresentação por meio de uma terceira camada que normalmente seria uma camada de negócios. Isso permite que você faça alterações em um único local, e não em toda a sua camada de apresentação.

Suponha que você decida alterar seu ORM de Linq para SQL para Entity Framework (ou nhibernate). Provavelmente será mais fácil alterá-lo na camada de negócios do que na camada de apresentação, pois a apresentação tende a se encaixar perfeitamente no seu modelo de apresentação.

Se você entende o MVC, ou seja, o Model View Controller, pode pensar na arquitetura de seu aplicativo em termos semelhantes. O modelo é análogo à sua camada de dados, a camada de apresentação é a visualização e a camada de negócios é o controlador.

Complementando a resposta do Desolate Planet sobre o Domain Driven Design:

Confira também The Onion Architecture , que está muito alinhado com os conceitos de Design Orientado a Domínio.

Observe como a "camada" da lógica de negócios é o núcleo da cebola e todas as camadas de infraestrutura (como a camada de acesso a dados) são suas dependências externas. Isso ajuda a testar muito, porque você deve poder zombar de todas as dependências de infraestrutura externa e testar completamente sua lógica de domínio.

Na minha opinião: a camada lógica de negócios é onde vive a "solução conceitual pura". O restante são apenas detalhes de implementação de infraestrutura.

No entanto, alguns aplicativos podem não precisar desse tipo de arquitetura. Se todos os seus aplicativos tiverem operações CRUD de conjunto de dados, sua 'solução conceitual pura' poderá estar praticamente vazia e tudo que você precisa é de um front-end de edição de banco de dados. Nesse caso, é melhor você focar apenas nas camadas DAL e UI.

A resposta a esta pergunta é (IMHO): "posso substituir completamente meu DAL e não precisar reescrever nenhum código de lógica de negócios"?

Pense nisso como sua camada de apresentação - é bastante comum pensar em mudar a GUI para outra, uma GUI de desktop espessa é trocada por um cliente da Web, que é trocada por um aplicativo para iPhone. Não é tão comum pensar assim no BLL / DAL, pois eles nunca são trocados, exceto talvez por algo muito semelhante (por exemplo, um banco de dados SQLServer substituído por um MySQL), mas se você imagina que precisou alterar seu banco de dados para um armazenamento distribuído serviço que foi acessado usando uma API, você pode ter uma idéia mais clara de onde as camadas se encontram.