- La agrupación de conexiones se maneja como en cualquier otra aplicación ADO.NET. La conexión de entidad todavía usa la conexión de base de datos tradicional con la cadena de conexión tradicional. Creo que puede desactivar la agrupación de conexiones en la cadena de conexión si no desea usarla. (lea más sobre la agrupación de conexiones de SQL Server (ADO.NET) )
- Nunca use el contexto global. ObjectContext implementa internamente varios patrones, incluidos Identity Map y Unit of Work. El impacto del uso del contexto global es diferente según el tipo de aplicación.
- Para aplicaciones web, utilice un contexto único por solicitud. Para los servicios web, use un solo contexto por llamada. En la aplicación WinForms o WPF, use un solo contexto por formulario o por presentador. Puede haber algunos requisitos especiales que no permitirán utilizar este enfoque, pero en la mayoría de las situaciones es suficiente.
Si desea saber qué impacto tiene el contexto de un solo objeto para la aplicación WPF / WinForm, consulte este artículo . Se trata de NHibernate Session pero la idea es la misma.
Editar:
Cuando usa EF, por defecto carga cada entidad solo una vez por contexto. La primera consulta crea instancia de entidad y la almacena internamente. Cualquier consulta posterior que requiera una entidad con la misma clave devuelve esta instancia almacenada. Si los valores en el almacén de datos cambiaron, aún recibirá la entidad con valores de la consulta inicial. Esto se llama patrón de mapa de identidad . Puede forzar el contexto del objeto para volver a cargar la entidad, pero volverá a cargar una sola instancia compartida.
Los cambios realizados en la entidad no persisten hasta que llame SaveChanges
al contexto. Puede hacer cambios en varias entidades y almacenarlas a la vez. Esto se llama patrón de unidad de trabajo . No puede decir selectivamente qué entidad adjunta modificada desea guardar.
Combina estos dos patrones y verás algunos efectos interesantes. Solo tiene una instancia de entidad para toda la aplicación. Cualquier cambio en la entidad afecta a toda la aplicación, incluso si los cambios aún no son persistentes (comprometidos). En la mayoría de los casos, esto no es lo que quieres. Suponga que tiene un formulario de edición en la aplicación WPF. Está trabajando con la entidad y decide cancelar la edición compleja (cambiar valores, agregar entidades relacionadas, eliminar otras entidades relacionadas, etc.). Pero la entidad ya está modificada en el contexto compartido. ¿Qué harás? Sugerencia: no conozco ningún CancelChanges o UndoChanges en ObjectContext
.
Creo que no tenemos que discutir el escenario del servidor. Simplemente compartir una sola entidad entre múltiples solicitudes HTTP o llamadas de servicio web hace que su aplicación sea inútil. Cualquier solicitud puede desencadenar SaveChanges
y guardar datos parciales de otra solicitud porque está compartiendo una sola unidad de trabajo entre todos ellos. Esto también tendrá otro problema: el contexto y cualquier manipulación con entidades en el contexto o una conexión de base de datos utilizada por el contexto no es seguro para subprocesos.
Incluso para una aplicación de solo lectura, un contexto global no es una buena opción porque probablemente desee datos nuevos cada vez que consulte la aplicación.