Instanciation d'un contexte dans LINQ to Entities
j'ai vu deux manières différentes que les programmeurs abordent lors de la création d'un contexte d'entité dans leur code.
La première est, comme tel, et vous pouvez tous les retrouver sur la MSDN exemples de code:
public void DoSomething() {
using (TaxableEducationEntities context = new TaxableEducationEntities()) {
// business logic and whatever else
}
}
la seconde est de créer le contexte en tant qu'attribut privé dans une classe qui encapsule votre logique d'affaires. Vous auriez donc quelque chose comme:
public class Education_LINQ {
private TaxableEducationEntities context = new TaxableEducationEntities();
public void DoSomething() {
var result = from a in context.luAction
select a;
// business logic and whatever else
}
}
Quel est le moyen le plus efficace?
Supposons que vous avez deux méthodes, l'une appelée DoSomething1 () et une autre appelée DoSomething2 (), et les deux méthodes incorporent l'instruction using pour ouvrir le contexte et faire n'importe quoi avec elle. Si vous appeliez une méthode après l'autre, y aurait-il des frais généraux superflus, puisque essentiellement les deux méthodes créent le contexte et le nettoient ensuite quand ils sont faits? Plutôt que d'avoir juste un attribut privé qui est créé lorsqu'un objet de classe est instanciée, et ensuite nettoyé lorsque l'objet passe de portée?
2 réponses
la création d'un nouveau Contexteobjectif implique à chaque fois une "certaine" surabondance. Il s'agit essentiellement de copier des métadonnées à partir d'un cache global dans des métadonnées associées à L'ObjectContext spécifique.
ces frais généraux sont relativement mineurs, si souvent qu'il ne vaut pas la peine de s'en inquiéter, surtout si l'on considère la sécurité supplémentaire inhérente à l'utilisation du modèle.
Pour moi, l'option que vous choisissez dépend des choses comme:
- Combien de temps vécu est votre habillage de classe susceptible d'être? Si il vit un longtemps L'ObjectContext pourrait développer pour maintenir beaucoup d'entités ralentir au fil du temps. Ainsi, un nouveau ObjectContext chaque fois pourrait être un bonne idée.
- Sont des appels à la méthodes sur votre classe d'emballage la synchronisation? ObjectContext la classe elle-même n'est pas thread-safe, donc si vous utilisez le deuxième modèle dont vous avez besoin assurez-vous que votre emballage classe / le dépôt est sécurisé si vous attendre plusieurs threads pour l'appeler.
- Sont les méthodes essentiellement pas liés? Si oui, vous pourriez obtenir des effets secondaires inattendus si elles partagent un contexte entre les méthodes.
en général ma recommandation est que si les méthodes sont apatrides, c.-à-d. le feu et oublier un nouveau contexte pour chaque méthode est probablement une bonne idée.
si toutefois vous avez une forme stateful ou quelque chose de relativement courte, alors peut-être qu'un contexte partagé est une meilleure idée.
mise à JOUR: j'ai pris le temps de les mettre ensemble un réponse plus complète
la deuxième option ne nettoie pas après elle-même si c'est ce que vous voulez dire. Je préfère utiliser la version ObjectContext à chaque fois parce que je n'ai pas à disposer après. Je ne suis pas sûr d'avoir bien compris la question... Trop d'heures de programmation d'aujourd'hui.
public class UserManagerRepository : IUserManagerRepository, IDisposable
{
private readonly Entities _context = new Entities();
private bool _disposed;
public User Create(User user, int countryId)
{
user.Country = GetCountry(countryId);
_context.AddToUser(user);
_context.SaveChanges();
return user;
}
}
alors pour utiliser ce dépôt je fais quelque chose comme:
using(var repository = new UserManagerRepository())
{
repository.Create(user);
}