MVC: Repositórios e Serviços

Question

Estou confuso quanto às limitações do que se define nos repositórios e o que deixar aos Serviços. Se o repositório apenas criar entidades simples correspondentes tabelas do banco de dados ou pode criar complexo objeto personalizado com combinações dessas entidades?

Em outras palavras: se Serviços de estar fazendo vários Linq para consultas SQL no repositório? Ou deveria todas as consultas ser predefinido no repositório e a lógica de negócios simplesmente decidir qual método para chamar?

Answer 1

Você realmente levantou uma questão aqui que está atualmente gerando muita discussão na comunidade de desenvolvedores - ver os comentários de acompanhamento para deve meu repositório expor IQueryable?

A lata repositório - e deve - criar combinação complexa objetos contendo vários associados entidades. Em Domain-Driven Design, estes são chamados de agregados - coleções de objetos associados organizados em uma estrutura coesa. Seu código não tem que GetCustomer() chamada, GetOrdersForCustomer(), GetInvoicesForCustomer() separadamente - você apenas chamar myCustomerRepository.Load(customerId), e você recebe de volta um objeto cliente profunda com essas propriedades já instanciado. Gostaria também de acrescentar que, se você estiver retornando objetos individuais com base em tabelas de banco de dados específicas, então isso é uma abordagem perfeitamente válida, mas não é realmente um repositório per sé -. É apenas uma camada de acesso a dados

Por um lado, há um argumento convincente de que os objetos Linq para SQL, com suas propriedades 'inteligentes' e sua execução adiada (ou seja, não carregar Customer.Orders até que você realmente usá-lo) são uma implementação completamente válido do padrão de repositório, porque você não está realmente a execução de código de banco de dados, você está executando instruções LINQ (que são depois traduzidas em código DB pelo provedor LINQ subjacente)

Por outro lado, como Matt Briggs' pontos pós fora, L2S é bastante intimamente ligado à sua estrutura de banco de dados (uma classe por tabela) e tem limitações (não muitos-muitos mapeamentos, por exemplo) - e você pode ser melhor fora de usar L2S para acesso a dados dentro o seu repositório, mas, em seguida, mapear o L2S objetos em seus próprios objetos do modelo de domínio e retornar aqueles.

Answer 2

Um repositório deve ser o único pedaço de seu aplicativo que sabe alguma coisa sobre a sua tecnologia de acesso de dados. Portanto, não deve estar retornando objetos gerados por L2S em tudo, mas mapear essas propriedades para objetos de modelo de sua preferência.

Se você estiver usando este tipo de padrão, você pode querer re pensar L2S. Gera-se uma camada de acesso de dados para você, mas não realmente lidar com diferença de impedância, você tem que fazer isso manualmente. Se você olhar para algo como NHibernate, que o mapeamento é feito de uma forma mais robusta. L2S é mais para uma aplicação de 2 camadas, onde você quer um DAL rápido e sujo que você pode estender facilmente.

Answer 3

Se você estiver usando LINQ, em seguida, minha crença é que o repositório deve ser um recipiente para sua sintaxe LINQ. Isto dá-lhe um nível de abstração das rotinas de acesso de banco de dados a partir do seu interface modelo de objeto. Como menciona Dylan acima, existem outros pontos de vista sobre o assunto, algumas pessoas gostam de voltar a IQueryable para que eles possam continuar a consultar o banco de dados em um ponto mais tarde, após o repositório. Não há nada de errado com qualquer uma dessas abordagens, contanto que você está claro em suas normas para sua aplicação. Há mais informaiton sobre as melhores práticas que eu uso para repositórios LINQ aqui.