É um trabalho duplo criando um componente de acesso a dados e um componente de negócios?

Question

Estou projetando meu primeiro aplicativo em camadas, que consiste em dados, negócios e camada de apresentação.

Meus componentes de negócios (por exemplo, negócios.comPonents.userComponent) atualmente possui o seguinte método:

public void Create(User entity)
{
    using (DataContext ctx = new DataContext())
    {
        ctx.Users.AddObject(entity);
        ctx.SaveChanges();
    }
}

Eu gosto desse design. No entanto, encontrei alguns exemplos on -line que recomendariam a seguinte implementação:

public void Create(User entity)
{
    // Instanciate the User Data Access Component
    UserDAC dac = new UserDAC();
    dac.InsertUser(entity);
}

Isso resultaria na criação de um componente de acesso a dados para todas as entidades, cada uma contendo os métodos básicos (Criar, editar, excluir ... etc).

Parece um trabalho duplo, pois eu teria que criar os componentes de acesso a dados com os métodos básicos, bem como os componentes de negócios que simplesmente chamam os métodos no componente de acesso a dados.

O que seria considerado as melhores práticas para implementar adequadamente as funcionalidades básicas do CRUD em um aplicativo em camadas? Eles devem ser 'codificados' no componente de negócios ou em um componente de acesso a dados?

Answer 1

Depende. Se você espera que sua camada de negócios simplesmente faça operações de CRUD, você pode seguir sua abordagem inicial. Se você planeja usar uma lógica de grandes empresas, onde o componente de negócios funcionará com muitas entidades, a segunda abordagem é melhor.

A razão pela qual as pessoas gostam de usar a segunda abordagem é testar e persistir a ignorância. Se você usar a primeira abordagem, seu componente de negócios estiver bem acoplado à estrutura da entidade. Zombar do ObjectContext não é uma tarefa muito fácil, portanto o teste é difícil. Se você usar a segunda abordagem, sua camada de negócios é independente na camada de persistência. Você pode testá -lo facilmente e pode até alterar a camada de persistência, se necessário. Mas esses são conceitos mais avançados que você provavelmente não está procurando no momento. Seu código precisaria de alguma melhoria adicional para ser testável.

O DAC também pode ser implementado como repositório. Existem várias maneiras de criar um repositório genérico para que você tenha apenas uma classe e defina o tipo de entidade ao instantar o repositório:

var repository = new GenericRepository<User>();

Esteja ciente de que o uso de camada de acesso a dados separado introduz nova complexidade, porque às vezes é razoável compartilhar um contexto único entre vários repositórios. Isso se junta a algo conhecido como unidade de padrão de trabalho.

Existem muitos artigos sobre a implementação de padrões de repositório e unidade de trabalho na Internet. Eu tenho alguns deles armazenados como favoritos em casa, por isso, se você estiver interessado, posso incluí -los na minha resposta mais tarde.