Conectando uma camada de negócios e um repositório usando o padrão de unidade de trabalho

Minha pergunta é semelhante a essa no Stack Overflow: Qual é a maneira correta de usar a Unidade de trabalho / repositórios na camada de negócios?

Cenário:

• Solução .Net
• IRepository usado para recuperar objetos do banco de dados
• IUnitOfWork usado para permitir transações entre vários repositórios

Isso faz sentido para mim e eu implementei algo nesse sentido que funciona bem. Agora, quero introduzir uma camada de lógica de negócios e estou com problemas para organizar os três elementos (BLL, UnitOfWork e Repository) em minha mente.

Meu entendimento:

• Repositório - recuperação, manipulação de dados
• UnitOfWork - persistência
• BLL - lógica relevante para os negócios ('mundo real') (não gosta desse termo!)

Considere que temos um front end do ASP.Net MVC.

Como é uma BLL e como é o controlador MVC que a usa?

Para referência: gostaria de saber se talvez a minha implementação IUnitOfWork / IRepository possa ser a causa subjacente da minha confusão.

public class IRepository<T> 
{
    private IObjectSet<T> objSet;
    public IRepository<T>(IUnitOfWork uow)
    {
        objSet = uow.CreateObjectSet<T>();
    }

    public IQueryable<T> Add(T entity)
    {
        objSet.Add(entity);
    }
    //etc. etc. for delete, attach, getall
}

Então, eu sinto que, se eu tiver um BLL, deveria passar o IUnitOfWork para que ele possa usá-lo para criar as instâncias de IRepository necessárias. Mas como a BLL (DLL separada do front-end) 'saberá' qual implementação do IRepository criar?

Observe que eu tenho apenas pouca experiência com a estrutura .NET e que esta resposta está relacionada apenas à parte da arquitetura da sua pergunta.

Pelo que entendi, você está basicamente aplicando os seguintes padrões de arquitetura em seu aplicativo:

Camadas: parece que você tem uma camada de persistência (padrão de repositório), uma camada de lógica de negócios e uma camada de visualização.

Controlador de exibição de modelo: esse padrão é aplicado na camada de exibição usando o ASP.NET MVC.

Acho que a pergunta é: como é um BLL e como é o controlador MVC que o usa?

Antes de tudo, essa arquitetura é destinada a aplicativos corporativos de larga escala, como Robert Harvey mencionou em seu comentário à sua pergunta. O que é característico para esses sistemas é que a lógica do domínio (que você encapsulou na camada da lógica de negócios) deve estar acessível por meio de várias interfaces.

Considere o Twitter, por exemplo - o Twitter poderia ter uma camada de lógica de negócios que fornece serviços para registrar e validar usuários, postar tweets e muito mais. No topo dessa camada de lógica de negócios, vários outros componentes podem existir na camada de visualização, por exemplo, uma interface da web e um componente de serviço da web. Como toda lógica de negócios está encapsulada na camada de lógica de negócios, é possível seguir o princípio DRY e melhorar a capacidade de manutenção e outros atributos de qualidade.

Para voltar à sua pergunta - você deve encapsular a lógica de negócios e o acesso a dados na BLL. O controlador (pense MVC) deve fazer uso da BLL e não deve ter acesso direto ao banco de dados. Considere a camada de visualização como uma interface para seu aplicativo.

Então, eu sinto que, se eu tiver um BLL, deveria passar o IUnitOfWork para que ele possa usá-lo para criar as instâncias de IRepository necessárias. Mas como a BLL (DLL separada do front-end) 'saberá' qual implementação do IRepository criar?

O BLL deve saber qual repositório (fonte de dados?) Ele usa. As camadas acima não devem controlar isso. Novamente, considere a camada de visualização apenas como uma interface para sua lógica de negócios.

Se você não precisar da sobrecarga de uma camada de lógica de negócios, também poderá optar por usá-la exclusivamente para acesso a dados na forma de objetos de acesso a dados .

Espero que isso tenha ajudado a esclarecer as responsabilidades dos vários componentes.