As múltiplas classes DataContext são apropriadas?

Question

Para utilizar totalmente o LinqToSql em uma aplicação ASP.net 3.5, é necessário criar DataContext Aulas (o que geralmente é feito usando o designer no VS 2008).Da perspectiva da UI, o DataContext é um design das seções do seu banco de dados que você gostaria de expor por meio do LinqToSql e é essencial na configuração dos recursos ORM do LinqToSql.

Minha pergunta é:Estou montando um projeto que utiliza um grande banco de dados onde todas as tabelas estão interligadas de alguma forma através de Chaves Estrangeiras.Minha primeira inclinação é criar uma classe DataContext enorme que modele todo o banco de dados.Dessa forma eu poderia em teoria (embora não saiba se isso seria necessário na prática) usar as conexões de Chave Estrangeira que são geradas através do LinqToSql para navegar facilmente entre objetos relacionados no meu código, inserir objetos relacionados, etc.

No entanto, depois de pensar um pouco, agora estou pensando que pode fazer mais sentido criar várias classes DataContext, cada uma relacionada a um namespace específico ou a uma seção lógica inter-relacionada em meu banco de dados.Minha principal preocupação é que instanciar e descartar uma enorme classe DataContext o tempo todo para operações individuais relacionadas a áreas específicas do banco de dados imporia uma imposição desnecessária aos recursos do aplicativo.Além disso, é mais fácil criar e gerenciar arquivos DataContext menores do que um grande.O que eu perderia é que haveria algumas seções distantes do banco de dados que não seriam navegáveis ​​através do LinqToSql (mesmo que uma cadeia de relacionamentos as conecte no banco de dados real).Além disso, haveria algumas classes de tabela que existiriam em mais de um DataContext.

Alguma ideia ou experiência sobre se vários DataContexts (correspondentes a namespaces de banco de dados) são apropriados no lugar de (ou além de) uma classe DataContext muito grande (correspondente a todo o banco de dados)?

Answer 1

Não concordo com a resposta de John.O DataContext (ou Linq to Entities ObjectContext) é mais uma "unidade de trabalho" do que uma conexão.Ele gerencia o rastreamento de alterações, etc.Veja esta postagem do blog para obter uma descrição:

Vida útil de um LINQ to SQL DataContext

Os quatro pontos principais desta postagem do blog são que DataContext:

1. É ideal para uma abordagem de "unidade de trabalho"
2. Também é projetado para operação do servidor "sem estado"
3. Não foi projetado para uso de longa duração

4. Should be used very carefully after
   any SumbitChanges() operation.
   

Considerando isso, não acho que usar mais de um DataContext causaria algum dano - na verdade, criar diferentes DataContexts para diferentes tipos de trabalho ajudaria a tornar sua execução LinqToSql mais utilizável e organizada.A única desvantagem é que você não seria capaz de usar o sqlmetal para gerar automaticamente seu dmbl.

Answer 2

Eu estava discutindo a mesma questão enquanto adaptava o LINQ to SQL em um banco de dados legado.Nosso banco de dados é um pouco incrível (150 tabelas) e depois de pensar e experimentar, optei por usar vários DataContexts.Ainda não se sabe se isso é considerado um antipadrão, mas por enquanto torna a vida administrável.

Answer 3

Acho que João está correto.

"Minha principal preocupação é que instanciar e descartar uma enorme classe DataContext o tempo todo para operações individuais relacionadas a áreas específicas do banco de dados imporia uma imposição desnecessária aos recursos do aplicativo"

Como você apóia essa afirmação?Qual é o seu experimento que mostra que um DataContext grande é um gargalo de desempenho?Ter vários contextos de dados é muito parecido com ter vários bancos de dados e faz sentido em cenários semelhantes, ou seja, quase nunca.Se você estiver trabalhando com vários contextos de dados, precisará controlar quais objetos pertencem a qual contexto de dados e não poderá relacionar objetos que não estejam no mesmo contexto de dados.Esse é um cheiro de design caro, sem nenhum benefício real.

@Evan "O DataContext (ou Linq to Entities ObjectContext) é mais uma" unidade de trabalho "do que uma conexão", é exatamente por isso que você não deve ter mais de um datacontext.Por que você iria querer mais de uma “unidade de trabalho” de cada vez?

Answer 4

Tenho que discordar da resposta aceita.Na questão colocada, o sistema possui um único grande banco de dados com fortes relacionamentos de chave estrangeira entre quase todas as tabelas (também é o caso onde trabalho).Nesse cenário, dividi-lo em DataContexts (DCs) menores tem duas desvantagens imediatas e principais (ambas mencionadas pela pergunta):

1. Você perde relacionamentos entre algumas tabelas. Você pode tentar escolher os limites do seu DC com sabedoria, mas eventualmente se deparará com uma situação em que seria muito conveniente usar um relacionamento de uma tabela em um DC para uma tabela em outro, e você não conseguirá.
2. Algumas tabelas podem aparecer em vários DCs. Isso significa que se você quiser adicionar métodos auxiliares específicos de tabela, lógica de negócios ou outro código em classes parciais, os tipos não serão compatíveis entre DCs.Você pode contornar isso herdando cada classe de entidade de sua própria classe base específica, o que fica confuso.Além disso, as alterações de esquema deverão ser duplicadas em vários controladores de domínio.

Agora, essas são desvantagens significativas.Existem vantagens grandes o suficiente para superá-las?A pergunta menciona desempenho:

Minha principal preocupação é que instancie e descarte uma enorme classe de datacontext o tempo todo para operações individuais relacionadas a áreas específicas do banco de dados seriam impor uma imposição desnecessária aos recursos de aplicativo.

Na verdade, não é verdade que um DC grande leve muito mais tempo para ser instanciado ou usado em uma unidade de trabalho típica.Na verdade, depois que a primeira instância é criada em um processo em execução, cópias subsequentes do mesmo DC podem ser criadas quase instantaneamente.

A única vantagem real de vários DCs para um único e grande banco de dados com relacionamentos completos de chaves estrangeiras é que você pode compartimentar seu código um pouco melhor.Mas você já pode fazer isso com aulas parciais.

Além disso, o conceito de unidade de trabalho não é realmente relevante para a questão original.Unidade de trabalho normalmente se refere a quanto trabalho um único DC instância está fazendo, não quanto trabalho um DC aula é capaz De fazer.

Answer 5

Na minha experiência com LINQ to SQL e LINQ to Entities, um DataContext é sinônimo de conexão com o banco de dados.Portanto, se você usasse vários armazenamentos de dados, precisaria usar vários DataContexts.Minha reação instintiva é que você não notaria muita lentidão com um DataContext que abrange um grande número de tabelas.No entanto, se você fizer isso, poderá sempre dividir o banco de dados logicamente em pontos onde poderá isolar tabelas que não têm nenhum relacionamento com outros conjuntos de tabelas e criar vários contextos.