São múltiplas classes de DataContext sempre adequada?

votos
27

A fim de utilizar plenamente LinqToSql em uma 3,5 aplicativo ASP.net, é necessário criar DataContext aulas (o que geralmente é feito usando o designer no VS 2008). Do ponto de vista da interface do usuário, o DataContext é um projeto das seções de seu banco de dados que você gostaria de expor a através LinqToSql e é parte integrante na criação dos recursos ORM de LinqToSql.

A minha pergunta é: estou a criação de um projeto que usa uma grande base de dados onde todas as tabelas estão interligados de alguma forma através de chaves estrangeiras. Minha primeira inclinação é fazer com que uma classe enorme DataContext que os modelos de todo o banco de dados. Dessa forma, eu poderia, em teoria (embora eu não sei se isso seria necessário na prática) usar as conexões de chave estrangeira que são gerados através LinqToSql para ir facilmente entre os objetos relacionados no meu código, inserir objetos relacionados, etc.

No entanto, depois de pensar um pouco, agora estou pensando que ele pode fazer mais sentido para criar múltiplas classes DataContext, cada uma relativa a um namespace específico ou seção interligados lógica dentro do meu banco de dados. A minha principal preocupação é que instanciar e descarte uma enorme classe DataContext todo o tempo para as operações individuais que se relacionam a áreas específicas do banco de dados seria impor uma imposição desnecessária de recursos de aplicativos. Além disso, é mais fácil criar e gerenciar arquivos DataContext menores do que um grande. A única coisa que eu iria perder é que haveria alguns trechos distantes do banco de dados que não seria navegável através LinqToSql (apesar de uma cadeia de relações conecta-los no banco de dados real). Além disso, haveria algumas classes da tabela que existem em mais de um DataContext.

Qualquer pensamento ou experiência sobre se vários DataContexts (correspondente a namespaces DB) são apropriadas no lugar de (ou além) de uma classe muito grande DataContext (correspondente a todo o DB)?

Publicado 05/08/2008 em 06:54
fonte usuário
Em outras línguas...                            


5 respostas

votos
25

Eu discordo com a resposta de John. O DataContext (ou Linq to Entities ObjectContext) é mais uma "unidade de trabalho" do que uma ligação. Ele gerencia o controle de alterações, etc. Veja este post para uma descrição:

Tempo de vida de um LINQ to SQL DataContext

Os quatro pontos principais deste post são de que DataContext:

  1. É ideal para uma "unidade de trabalho" abordagem
  2. também é projetado para a operação do servidor "apátrida"
  3. Não é projetado para uso de longa duração
  4. Should be used very carefully after
    any SumbitChanges() operation.
    

Considerando isso, eu não acho que usar mais de um DataContext faria qualquer harm- na verdade, criando diferentes DataContexts para diferentes tipos de trabalho seria ajudar a tornar sua impelmentation LinqToSql mais usuable e organizado. A única desvantagem é que você não seria capaz de usar sqlmetal para gerar automaticamente o seu dmbl.

Respondeu 07/08/2008 em 22:02
fonte usuário

votos
4

Eu estava discutindo sobre a mesma pergunta enquanto retro montagem LINQ to SQL durante um DB legado. Nosso banco de dados é um pouco de uma grande mentira (150 mesas) e depois de algum pensamento e experimentação I eleito para usar vários DataContexts. Se este é considerado um anti-padrão continua a ser visto, mas por enquanto isso torna a vida administrável.

Respondeu 05/08/2008 em 23:51
fonte usuário

votos
3

Eu tenho que discordar com a resposta aceita. Na questão colocada, o sistema tem um único banco de dados grande, com fortes relações de chave estrangeira entre quase todas as mesas (também o caso onde eu trabalho). Neste cenário, dividindo-o em DataContexts menores (DC) tem duas desvantagens imediatas e grandes (ambos mencionados pela pergunta):

  1. Você perde relações entre algumas tabelas. Você pode tentar escolher seus limites DC sabiamente, mas você acabará por correr em uma situação onde seria muito conveniente de usar uma relação de uma tabela em um DC para uma mesa na outra, e você não será capaz de.
  2. Algumas tabelas podem aparecer em múltiplos DC. Isto significa que se você quiser adicionar métodos específicos de mesa ajudante, lógica de negócio, ou outro código em classes parciais, os tipos não será compatível em DC. Você pode contornar esse herdando cada classe de entidade a partir de sua própria classe base específica, que fica confuso. Além disso, as mudanças de esquema terá de ser duplicado através de vários DC.

Agora esses são desvantagens significativas. Existem vantagens grande o suficiente para superá-los? A questão menciona desempenho:

A minha principal preocupação é que instanciar e descarte uma enorme classe DataContext todo o tempo para as operações individuais que se relacionam a áreas específicas do banco de dados seria impor uma imposição desnecessária de recursos de aplicativos.

Na verdade, não é verdade que um grande DC leva muito mais tempo para instanciar ou usar em uma unidade típica de trabalho. De fato, após a primeira instância é criada em um processo em execução, cópias subsequentes do mesmo DC podem ser criados quase instantaneamente .

A única vantagem real a partir de múltiplos DC para um único grande banco de dados, com relações de chave estrangeira completas é que você pode compartimentar o seu código um pouco melhor. Mas você já pode fazer isso com classes parciais.

Além disso, a unidade do conceito de trabalho não é realmente relevante para a pergunta original. Unidade de trabalho normalmente se refere a quanto uma obra de um único DC instância está fazendo, e não a quantidade de trabalho a DC classe é capaz de fazer.

Respondeu 17/06/2014 em 21:53
fonte usuário

votos
3

Eu acho que John está correto.

"Minha principal preocupação é que instanciar e descarte uma enorme classe DataContext todo o tempo para as operações individuais que se relacionam a áreas específicas do banco de dados seria impor uma imposição desnecessária sobre os recursos do aplicativo"

Como você sustentar essa afirmação? Qual é a sua experiência que mostra que um grande DataContext é um gargalo de desempenho? Tendo vários datacontexts é muito parecido com ter vários bancos de dados e faz sentido em situações semelhantes, ou seja, quase nunca. Se você estiver trabalhando com vários datacontexts você precisa manter o controle de quais objetos pertencem a qual DataContext e você não pode se relacionar objetos que não estão no mesmo contexto de dados. Isto é um cheiro projeto caro para nenhum benefício real.

@Evan "O DataContext (ou Linq to Entities ObjectContext) é mais uma 'unidade de trabalho' do que uma conexão" É precisamente por isso que você não deve ter mais de um datacontext. Por que você quer mais do que uma "unidade de trabalho" de cada vez?

Respondeu 27/08/2008 em 02:11
fonte usuário

votos
1

Na minha experiência com LINQ to SQL e LINQ to Entities um DataContext é sinônimo de uma conexão com o banco de dados. Então, se você fosse usar vários armazenamentos de dados você precisa usar vários DataContexts. Minha reação instintiva é que você não vai notar muito de um lento para baixo com um DataContext que engloba um grande número de mesas. Se você fez, contudo, você pode sempre dividir o banco de dados logicamente em pontos onde você pode isolar tabelas que não têm qualquer relação com outros conjuntos de mesas e criar múltiplos contextos.

Respondeu 05/08/2008 em 10:57
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more