- O pool de conexões é tratado como em qualquer outro aplicativo ADO.NET. A conexão de entidade ainda usa a conexão tradicional do banco de dados com a seqüência de conexão tradicional. Acredito que você pode desativar o pool de conexões na cadeia de conexão se não quiser usá-lo. (leia mais sobre o pool de conexões do SQL Server (ADO.NET) )
- Nunca use o contexto global. O ObjectContext implementa internamente vários padrões, incluindo Mapa de Identidade e Unidade de Trabalho. O impacto do uso do contexto global é diferente por tipo de aplicativo.
- Para aplicativos da Web, use um contexto único por solicitação. Para serviços da Web, use um contexto único por chamada. No aplicativo WinForms ou WPF, use o contexto único por formulário ou por apresentador. Pode haver alguns requisitos especiais que não permitirão usar essa abordagem, mas na maioria das situações isso é suficiente.
Se você deseja saber qual impacto possui um contexto de objeto único para o aplicativo WPF / WinForm, consulte este artigo . É sobre o NHibernate Session, mas a idéia é a mesma.
Editar:
Quando você usa EF, por padrão, carrega cada entidade apenas uma vez por contexto. A primeira consulta cria instace de entidade e a armazena internamente. Qualquer consulta subsequente que exija entidade com a mesma chave retorna essa instância armazenada. Se os valores no armazenamento de dados foram alterados, você ainda recebe a entidade com valores da consulta inicial. Isso é chamado de padrão de mapa de identidade . Você pode forçar o contexto do objeto a recarregar a entidade, mas ele recarregará uma única instância compartilhada.
Quaisquer alterações feitas na entidade não serão mantidas até você chamar SaveChanges
o contexto. Você pode fazer alterações em várias entidades e armazená-las de uma só vez. Isso é chamado de padrão de Unidade de Trabalho . Você não pode dizer seletivamente qual entidade anexa modificada deseja salvar.
Combine esses dois padrões e você verá alguns efeitos interessantes. Você tem apenas uma instância da entidade para todo o aplicativo. Quaisquer alterações na entidade afetam todo o aplicativo, mesmo que as alterações ainda não sejam persistidas (confirmadas). Na maioria das vezes, isso não é o que você deseja. Suponha que você tenha um formulário de edição no aplicativo WPF. Você está trabalhando com a entidade e decide cancelar edições complexas (alteração de valores, adição de entidades relacionadas, remoção de outras entidades relacionadas etc.). Mas a entidade já está modificada em contexto compartilhado. O que você vai fazer? Dica: não conheço nenhuma CancelChanges ou UndoChanges emObjectContext
.
Acho que não precisamos discutir o cenário do servidor. O simples compartilhamento de uma única entidade entre várias solicitações HTTP ou chamadas de serviço da Web torna seu aplicativo inútil. Qualquer solicitação pode apenas dispararSaveChanges
e salvar dados parciais de outra solicitação, porque você está compartilhando uma única unidade de trabalho entre todas elas. Isso também terá outro problema - o contexto e qualquer manipulação com entidades no contexto ou uma conexão de banco de dados usada pelo contexto não é segura para threads.
Mesmo para um aplicativo somente leitura, um contexto global não é uma boa opção, porque você provavelmente deseja novos dados sempre que consultar o aplicativo.