Différence entre NHibernate SessionFactory et EF 4.0 ObjectContext

Question

Dans NHibernate, SessionFactory est considéré comme un objet lourd et il est suggéré que SessionFactory soit créé une fois dans la durée de vie de l'application. Cependant, une fois que nous obtenons la gestion de SessionFactory, nous appelons open() avant d'effectuer une opération DB.

Dans EntityFramework, nous devons créer un objet ObjectContext à chaque fois avant d'effectuer une opération avec le magasin sous-jacent. Il n'y a pas d'ouverture en tant que telle dans le cas d'EF.

Ma question est:

crée un contexte EF est similaire à l'appel (Open) sur SessionFactory NHibernate?

Ou dois-je créer ObjectContext une fois dans la durée de vie de l'application et le partager?

Mise à jour: J'ai trouvé le lien suivant sur la gestion de la durée de vie ObjectContext. Cependant, dans cet auteur de lien mentionne:

http://dotnetslackers.com/articles/ado_net/Managing-Entity-Framework-ObjectContext-lifespan-and-scope-in-n-layered-ASP-NET-applications.aspx#1390

Cependant, vous ne devriez pas utiliser un statique ObjectContext dans une application ASP.NET , puisque les membres statiques ont une durée de vie au-delà d'un simple Requête HTTP. Ils sont en fait lié à la durée de vie de l'AppDomain , qui peut être minutes ou heures. En fait, les membres de classes statiques dans ASP.NET sont même partagés entre plusieurs threads et les utilisateurs de l'application . En utilisant la même instance ObjectContext de plusieurs threads simultanément peuvent causer des problèmes graves.

Mais dans NHibernate, nous faisons exactement la même chose. Nous créons SessionFactory comme un champ statique, puis utilisons la même instance à travers l'application encore et encore.

Est-ce que cela est suggéré comme une mauvaise pratique dans le cas d'Entity Framework?

Answer 1

L'OC dans EF est plus proche de la Session dans NH que de la SessionFactory.