IQueryable & Repositories – pegue 2?

Tenho que admitir que estou carregando o banner “Repositório não deve retornar IQueryable” porque é mais difícil de testar. Fui influenciado pelas respostas a outras perguntas como esta e esta .

Esta manhã eu tenho lido o blog do ScuttGu sobre ASP.NET vNext onde ele detalha Model Binding usando um SelectMethod que parece confiar no IQueryable para paginação e sorting.

Você acha que isso nos forçará a reconsiderar a function que o IQueryable desempenha nos repositorys?

O Repositório DDD deve encapsular os detalhes técnicos dos dados:

Definição: Um Repositório é um mecanismo para encapsular armazenamento, recuperação e comportamento de pesquisa que emula uma coleção de objects.

Também é responsável por lidar com o meio e fim de vida dos objects de domínio. Interface de repository pertence ao domínio e deve ser baseada na linguagem ubíqua , tanto quanto possível. Além do livro DDD, esses dois artigos cobrem quase tudo que você precisa saber ao criar repositorys:

  • Como escrever um repository
  • O Repositório Genérico

Expor IQueryable na interface do repository não é ideal na minha opinião. IQueryable não faz parte da linguagem ubíqua. É um detalhe técnico, não tem significado de domínio. Em vez de encapsular a recuperação de dados, o Repository exporia o mecanismo de access a dados simples, o que essencialmente anula o propósito de ter o Repository em primeiro lugar.

Em relação ao ASP.NET. Este é um framework de interface do usuário. Por que você permitiria que a estrutura da interface do usuário afetasse o design do seu modelo de domínio? Os exemplos da Microsoft muitas vezes incentivam coisas como a grade de dados da interface do usuário vinculada diretamente às suas tabelas de database. Ou, mais recentemente, os controles são vinculados ao que é chamado de Modelo de Domínio, enquanto na verdade é um Modelo Anêmico , ou simplesmente um contêiner de dados estúpido com gets / sets. A citação do artigo que você mencionou (eu coloquei um pouco de ênfase):

A vinculação de modelo é uma abordagem cinput em código para vinculação de dados . Ele permite que você escreva methods auxiliares CRUD dentro do arquivo code-behind de sua página e, em seguida, conecte-os facilmente a qualquer controle de servidor dentro da página. Os controles de servidor, então, cuidarão de chamar os methods no momento apropriado no ciclo de vida da página e vincularão os dados aos dados .

Minha interpretação disso é eliminar o modelo e os objects e apenas vincular seus dados à interface do usuário. Esta é provavelmente uma abordagem válida e justificada em muitos casos. Mas como a pergunta foi marcada como DDD, eu diria que no DDD isso é chamado de Smart UI Anti-Pattern .