padrão de repositório com um banco de dados legado e LINQ to SQL

Question

Estou construindo uma aplicação em cima de um banco de dados legado (que eu não posso mudar). Estou usando o Linq para SQL para o acesso aos dados, o que significa que eu tenho um (LINQ to SQL) classe para cada tabela.

O meu modelo de domínio não coincide com o banco de dados. Por exemplo, existem duas tabelas nomeadas Users e Employees, e, portanto, eu tenho dois LINQ to SQL classes chamadas User e Employee. Mas no meu modelo de domínio que eu gostaria de ter uma classe User que deve conter alguns campos de ambas as tabelas (mas eu não me importo com um monte de outros campos dessas tabelas).

Eu não sei como eu deve projetar meus repositórios:

• deve repositórios executar o mapeamento entre Linq para classes de SQL (por exemplo User Employee,) para as classes de domínio (User) e retornar apenas as classes de domínio para a aplicação
• ou deveria meus repositórios devolver o Linq para as classes SQL e deixar o mapeamento para o chamador

A primeira abordagem parece fazer mais sentido para mim, mas esta é a maneira correta de implementar meus repositórios?

Answer 1

O purista (eu tento ficar puro) irá dizer-lhe que seu modelo representa seus dados. E, portanto, qualquer coisa que precisa ser persistido é feito somente quando necessário, através de repositórios. Além disso, quando você tem entidades complexas, que pretende utilizar um serviço de combiná-los. Por exemplo, o usuário + Empregado = entidade UserEmployee que só é acessível através de um IUserEmployeeService.

Com essas declarações vagas, você tem uma excelente oportunidade aqui.

Construir uma camada anti-corrupção, que permite que você começar a se mover para fora da DB legado ao mesmo tempo.

Este é um outro capítulo na cartilha DDD. camada de um Anti-Corrupção é usado para a interface com um sistema legado usando Fachadas, tradutores e adaptadores para isolar o legado DB com o seu modelo de domínio puro.

Agora, isso pode ser muito mais trabalho do que você queria. Então, você tem que perguntar-se neste ponto:

Do Quero começar o processo de afastando-se deste legado DB, ou vontade que permanecem para a vida do aplicação?

Se a sua resposta é, você pode iniciar a migração, então modelar seu domínio real do jeito que você quiser. Persistir com repositórios e serviços normais. Divirta-se projetar do jeito que você quer que ele armazenado. Em seguida, use os serviços das raízes agregado para chegar na camada anti-corrupção e retirar as entidades, loja / atualizá-los localmente, e traduzir-se em entidades do seu domínio.

Se a resposta é que o legado DB permanecerá para a duração do projeto, em seguida, sua tarefa é muito mais fácil. Utilize os serviços do seu domínio (por exemplo UserEmployeeService) para chegar em UserFacade do anti-corrupção e EmployeeFacade (similar a um conceito "Remote Service").

Dentro das fachadas, o acesso a db legado usando os adaptadores (por exemplo LegacyDbSqlDatabase) para obter uma legacyUser matéria (). O próximo passo seria a utilização de um UserTranslator () e mapeador EmployeeTranslator () que converte os dados do usuário legado para a versão de seu domínio real da entidade User (), e devolvê-lo na parte de trás UserFacade ao seu UserEmployeeService, onde é combinado com a entidade Employee que veio do mesmo lugar.

Whoa, que era um monte de digitação ...

Com os adaptadores e Fachadas de sua camada de Anti-Corrupção, você pode fazer sua Linq-to-SQL ou o que você quer fazer. Não importa porque você isolou completamente o legado DB / sistema longe do seu agradável e Domínio puro - seu domínio que tem a sua própria versão do User () e empregado () entidades e objetos de valor.

Answer 2

DDD e LINQ to SQL não combinam muito bem porque as classes geradas não são destinadas a desviar-se significativamente a partir de sua estrutura de tabela DB. Você vai ter que quer mapear suas classes de uma maneira que faz com que trabalhar com LINQ to SQL uma dor ou apenas ao vivo com um modelo de objeto não-ideal.

Se você realmente quiser utilizar DDD e o padrão de movimento repositório para Entity Framework ou até melhor NHibernate.