Onde devo colocar lógica de negócios quando estou usando o padrão de repositório?

Question

Eu estou usando o padrão de repositório para a minha candidatura. Eu tenho uma classe de usuário. Usuário é identificado por e-mail. O UserRepository contém um método CreateUser (utilizador do utilizador). Há uma regra de negócio dizendo que os usuários devem ter um e-mail exclusivo.

Eu quero implementar uma transação que primeiro verifica se um e-mail está em uso e se não, o usuário é criado. Onde devo colocar esse código que é responsável pela verificação da unicidade do e-mail?

Esta é definitivamente uma regra de negócio; é a lógica de negócios. Eu acho que não é correto colocar esse check-in minha implementação UserRepository.

Answer 1

Este tipo de coisa vai tipicamente em qualquer (1) um serviço ou (2) diretamente no esquema como uma restrição de banco de dados (e freqüentemente ambos).

Usando um serviço, você não acessar o repositório diretamente do código de cliente; você chama um serviço que faz as operações úteis para você.

Por exemplo, algo como:

public class UserService : ... {
  private Repository<User> _userRepository;

  public void CreateUser(User u) {
    // Verify that the user's email is unique.
    if ( ... ) {
      _userRepository.Create(u);
    }
  }
}

Answer 2

Se você está construindo um grande o suficiente aplicativo para Warrent um padrão de repositório então você' vai querer colocar esta validação o mais próximo do número de dados possível, provavelmente uma restrição de banco de dados, tais como um índice de / chave única. Isto evita situações de erros vazamento em código mais tarde devido a dados corrompidos.

Answer 3

Assumindo que você está usando um banco de dados para armazenamento, você deve definitivamente adicionar uma restrição de unicidade para a coluna de e-mail no banco de dados.

Answer 4

Confira este excelente artigo na conversa simples:

Cinco erros simples de banco de dados projeto que você deve evitar

Veja na Seção 4:

impor a integridade através de aplicações

Os defensores da aplicação baseada integridade geralmente argumenta que restrições negativamente dados de impacto Acesso. Eles também assumem seletivamente aplicação de regras com base nas necessidades de a aplicação é a melhor rota para leva. .....

A solução é simples.

Conte com mais nada para oferecer integralidade e exactidão, exceto o próprio banco de dados. por nada, eu significa nem os utilizadores nem aplicações externo para o banco de dados. **

Assim, no seu caso - uma restrição exclusiva em sua coluna de e-mail deve realmente ser modelado no banco de dados. Esse é o melhor lugar para colocar esse pedaço de lógica de negócios e irá salvá-lo de muita dor no longo prazo.

Marc