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 ...
Honestamente, apesar de algumas armadilhas que nós vimos chegando (cruzamento complexo), o enorme .edmx funcionou bem de uma perspectiva de "trabalho". Mas você terá que tomar cuidado com a mágica de "conserto" que o contexto faz por trás da cena, se você não a desabilitar explicitamente. Além de manter o .edmx em sincronia quando as alterações no banco de dados são feitas ... algumas vezes foi mais fácil limpar toda a superfície e recriar as entidades, o que demorou 3 minutos, então não foi nada demais.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.