BT

Contornando os Problemas de grandes Modelos de Dados no Entity Framework

por Jonathan Allen , traduzido por Flávia Castro de Oliveira em 15 Dez 2008 |

Srikanth Mandadi, o líder do desenvolvimento do Entity Framework, chamou o artigo de duas partes de "Trabalhando com Grandes Modelos no Entity Framework", mas fica claro que eles querem dizer 'como fazer uma gambiarra' em relação a isso. O artigo começa com o número esperado de entities para uma determinada aplicação, com 50 à 100 entities. Mais que isso o editor torna-se praticamente inutilisável.

O Entity Framework tem alguns problemas surpreendentes de performance. Por exemplo, os metadados baseados em XML para todo o modelo de dados é carregado na memória cada vez que uma nova string de conexão é usada. Se você tem um conjunto de pequenas aplicações que compartilham um modelo comum de dados, adicionando novas entities a qualquer uma delas, fará com que todas fiquem lentas. Esta limitação coloca os modelos de dados do Entity Framework em bibliotecas compartilhadas insustentáveis.

Visualizar a geração é outra área onde o design do Entity Framework mostra falhas significativas. Srikanth Mandadi explica,

O processo funciona a primeira vez que cada query ou SaveChanges acontece. A performance de vizualizar a etapa de geração não depende somente do tamanho de seu modelo, mas também da forma de como o modelo está interligado. Se duas Entities são conectadas através de uma corrente de herança ou uma Associação, diz-se que elas estão conectadas. Do mesmo modo, se duas tabelas são conectadas através de uma chave estrangeira, elas estão conectadas. Como o número de Entities e tabelas conectadas em seu schema aumenta, o custo da visualização da geração aumenta.

Para contornar esses problemas, Srikanth Mandadi sugere dividir grandes modelos de dados em pequenos subconjuntos. Há duas maneiras de fazer isso, apesar de que ambos não parecem corretos.

A primeira foram é simplesmente usar subconjuntos completamente separados. Se uma tabela está precisando de dois ou mais subconjuntos, é criada uma entity separada para cada uma. Isso torna chamadas diretas através de subconjuntos impossível e conduz ao exagero.

Uma outra opção é a "Utilização" da syntax no schema. O IDE não suporta isso, ele exige editar manualmente o XML para indicar que um banco de dados deverá usar entities a partir de um outro modelo de dados. Além da dor de editar manualmente o XML, só se pode criar links de sentido único dessa forma. Se o modelo de dados 'A' utiliza entities a partir do modelo de dados 'B', o modelo de dados 'B' não pode ter referências de volta ao modelo de dados 'A'.

Você pode ler toda a Parte 1 e a Parte 2 no Blog ADO.NET Team.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT