Entity Framework ObjectContext en la aplicación windows/WPF/Silverlight

Question

Estamos escribiendo una aplicación WPF utilizando Entity framework (Silverlight con servicios de RIA para ser precisos). Estamos utilizando un ObjectContext compartido a través de la aplicación para que podamos aprovechar el intercambio de datos entre los módulos.

El problema es que si el usuario abre durante su trabajo, digamos las ventas históricas, se carga al ObjectContext y permanece allí hasta el final de la aplicación. Entonces otro patrón debería ser usado.

Sé que ObjectContexts se debe utilizar como unidad de trabajo individual. Pero entonces, ¿cómo se permite que otras partes de la aplicación sepan que algo ha cambiado y que deberían volver a cargar sus datos?

Editar: Ok, EventAggregator, pero entonces, esto haría que todas las demás partes volvieran a cargar sus datos (probablemente la mayoría duplicados). También probablemente se necesitarían muchos eventos para todos los tipos de grupos de entidades.

¿Cómo resuelves estos problemas? Mi solución actual es una especie de compromiso: utilice un ObjectContext compartido para los datos centrales utilizados por la aplicación completa, de modo que puedan compartirse y actualizarse automáticamente. Y para la gran cantidad de datos, use un nuevo ObjectContext separado. Alguna mejor idea?

¿Hay alguna manera de "liberar" entidades de su DataContext para que Garbage collector pueda hacer su trabajo y liberar la memoria?

Answer 1

Espera, ¿es WPF o Silverlight? En este caso, son muy diferentes y mi respuesta sería diferente.

WPF Solución

En WPF me gustaría crear una sola forma ObjectContext por. De esta manera, el contexto solo durará tanto como la forma misma. A continuación, debe implementar un sistema de eventos para que cuando guarde los cambios en una entidad pueda alertar a los otros formularios que pueden necesitar para actualizar sus datos (INotifyPropertyChanged, por ejemplo). Oren Eini wrote a pretty good article on this architecture using NHibernate in MSDN magazine. Debería poder obtener el concepto de arquitectura de su artículo.

Silverlight Solución

Ahora, Silverlight es diferente. Silverlight esencialmente solo le permite tener un formulario en su aplicación. Sí, hay algunos trucos que puede realizar para navegar por la vista de raíz del formulario a diferentes "páginas", pero sigue siendo solo un formulario y el usuario no puede abrir varias ventanas en un Silverlight RIA. Por este motivo, crearía un .NET RIA Services ObjectContext por instancia Silverlight RIA. Recuerde, RIA Services no es una conexión real a su base de datos, es solo un caché y un objeto de seguimiento de cambios vinculado a un servicio web. Por lo tanto, es perfectamente aceptable dejar este objeto en existencia por períodos de tiempo más largos porque no está atando ningún recurso del servidor. Si su RIA de Silverlight abre varias ventanas del navegador o tiene más de un objeto de Silverlight, entonces debe tener un ObjectContext por instancia de Silverlight.

En el servidor, utiliza Entity Framework ObjectContext en el servicio web y solo debe durar una solicitud. Cuanto más apátridas pueda hacer sus servicios, más escalables y eficientes serán. Desea abrir su EF ObjectContext, usarlo y cerrarlo lo antes posible.

---

EDIT:

Si todo lo que están queriendo hacer es separar un objeto del contexto del objeto, a continuación, puedes usar el método context.Detach(entity). Puede encontrar un example of how to do this on MSDN.

Answer 2

Puede usar el patrón de repositorio. Una capa adicional de abstracción entre UI y DAL.

Hacer colecciones de datos en el repositorio estáticas y observables. Luego, cada vez que el repositorio actualice alguno de ellos, la capa UI debería ponerse al día. Solo una idea.

Answer 3

Use ObservableCollections en ObjectContext. Use un evento que se desencadene en NotifyPropertyChange. Utilice un patrón de publicación/suscripción entre los modelos de visualización para informarles sobre el cambio y utilícelo para actualizar las otras vistas.

Answer 4

En nuestro caso, hemos decidido implementar un patrón de fábrica y crear una instancia de un nuevo contexto de objetos siempre que lo necesitemos (a veces no asigna uno a uno a una VM).

de Agreat artículo sobre el tiempo de vida de objetos de contexto: http://www.silverlightshow.net/items/Silverlight-WCF-RIA-Services-strategies-for-handling-your-Domain-Context-part-one.aspx