Entity Framework com sistemas grandes - como dividir modelos?

Pessoalmente, tentei criar um enorme esquema para todas as minhas entidades em um projeto bastante complexo, mas pequeno (~ 300 tabelas). Nós tínhamos um banco de dados extremamente normalizado (5ª forma de normalização (digo vagamente)) com muitos relacionamentos "muitos para muitos" e aplicação extrema de integridade referencial.

Também usamos uma estratégia de "instância única por solicitação" que também não estou convencida de ajuda.

Ao fazer listas, pesquisas e pesquisas simples, razoavelmente definidas, "explicitamente definidas", geralmente é aceitável. Mas quando começamos a nos aprofundar em relacionamentos profundos, o desempenho pareceu diminuir drasticamente. Comparado a um procedimento armazenado neste exemplo, não houve comparação (claro). Tenho certeza de que poderíamos ter ajustado a base de código aqui e ali para melhorar o desempenho, no entanto, neste caso, só precisávamos de aumento de desempenho sem análise devido a restrições de tempo, e voltamos ao procedimento armazenado (ainda mapeado através da EF, porque a EF forneceu resultados strongmente tipados), nós só precisávamos disso como um recuo em algumas áreas. Quando tivemos que percorrer todo o banco de dados para criar uma coleção (usando .include () unsparingly), o desempenho estava consideravelmente degradante, mas talvez estivéssemos perguntando muito ..

Portanto, com base em minha experiência, recomendo criar um .edmx por intenção. Gere apenas o que você vai usar com base no escopo dessa necessidade. Você pode ter alguns arquivos .edmx com escopo menor para tarefas propostas e, em seguida, alguns grandes, em que é necessário atravessar relacionamentos complexos para criar objetos. Não tenho certeza de onde é esse ponto mágico, mas tenho certeza que tem um ... rsrs ...

Isso foi tudo com o EntityFramework 4.1. Eu estaria realmente interessado em ouvir sobre sua escolha final e experiência também.

E em relação a sua pergunta sobre o nHibernate, é uma questão de latas de vermes, na minha opinião, você vai latir nos dois lados da cerca ... Eu ouço muita gente batendo a EF para bater sem trabalhando através dos desafios e entendendo as nuances exclusivas da própria EF .. e embora eu nunca tenha usado o nHibernate em produção, geralmente, se você tiver que criar manualmente e explicitamente coisas como mapeamentos, você terá um controle mais finito, no entanto , se você pode arrastar e soltar, gerar e iniciar o CRUD e consultar usando o LINQ, eu poderia dar uma porcaria sobre granularidade.

Espero que isso ajude.

Deixem-me começar por um simples esclarecimento: não tenho experiência com uma base de dados tão grande, pelo que o resto da minha resposta não se baseia no exemplo do mundo real.

Então você tem um banco de dados GRANDE e quer usá-lo com o ORM / EF. Eu iria com a segunda escolha. Aqui está a minha explicação simples porque:

• O mapeamento adiciona complexidade. Não há necessidade de adicionar complexidade às entidades que seu aplicativo / projeto / módulo atual nunca precisa, mas não torna a granularidade muito baixa. Ter um conjunto separado de mapeamento por tela também não o ajudará.
• Você deseja alcançar a unidade de trabalho. Você deve ser capaz de especificar o que o módulo de tabelas precisa na maioria dos casos (não é necessário em todos os casos). Se você colocar essas tabelas em um único conjunto de mapeamento, poderá manipular a leitura e a modificação de dados por uma única instância de contexto - eis qual deve ser seu destino final.
• Não sei exatamente o que você quer dizer com modelo, mas mesmo com conjuntos de mapeamento diferentes, é possível compartilhar classes entre conjuntos de mapeamento usando os mesmos tipos de entidade. Portanto, se você usar a tabela de usuários em dois módulos, não precisará de duas classes de usuário para representar as mesmas. Você ainda pode usar uma única tabela e no caso de mapeamento de código (também conhecido como code-first) você pode definir o mapeamento uma vez e carregá-lo em vários conjuntos de mapeamento para que o princípio DRY não seja violado, mas a abordagem code-first tem mais limitações para exibições e procedimentos armazenados. EDMX torna isso mais difícil. Ainda é possível reutilizar classes, mas é impossível reutilizar o mapeamento.
• E quanto às consultas entre módulos? Estas perguntas podem acontecer, mas para ser honesto, nem tudo deve ser tratado pela EF. Você pode aproveitar o EF para casos comuns para simplificar o acesso regular a dados, mas se você precisar de uma consulta especial que junte tabelas pertencentes a 5 módulos diferentes, basta executá-lo diretamente ou agrupá-lo no procedimento armazenado. A substituição de 100% do acesso a dados nativos pode ser difícil, complexa e contraproducente.
• O último ponto é simplesmente prático: não acredito que o ferramental VS esteja pronto para trabalhar com um conjunto tão grande de objetos - não no designer, nem mesmo com a ferramenta de importação. Eu costumava trabalhar em um banco de dados muito grande com acesso a dados tradicional e projeto de banco de dados SQL no VS2008 - a experiência do usuário com um projeto complexo era muito ruim. Você deve manter o número de tabelas usadas baixo - o limite para o designer deve estar entre 100-200, mas até 100 tabelas tratadas por contexto único (conjunto de mapeamento) soa como muita responsabilidade para uma classe (suponha que você tenha 100 propriedades definidas exposta no contexto - não parece um bom design).

Eu diria que você não pode decidir esse tipo de pergunta a partir de uma perspectiva técnica. Eu recomendo que você construa sua arquitetura com base em seus casos de uso (histórias de usuários, etc.). Primeiro, encontre seus objetos de negócios. Um objeto de entidade não é, por padrão, um objeto de negócios. Típico você terá um objeto de negócios na frente dos objetos de entidade. Em seguida, você pode decidir de forma incremental o que realmente precisa, com base nos requisitos do usuário.

"Um bom arquiteto maximiza o número de decisões não tomadas." Robert C. Martin

link

Eu uso uma abordagem híbrida - o material OLTP é tratado pelo EF enquanto operações pesadas como inserções em lote, atualizações em massa, consultas de relatórios, etc. são tratadas por Procs Armazenados. Isso também torna o caminho de migração mais fácil se você não estiver fazendo uma re-gravação completa da sua camada de dados de uma só vez.