Consommation et performances de la mémoire ObjectContext

Question

Je souhaite écrire une couche d'objet métier de sorte que chaque objet entité soit responsable de l'enregistrement de ses propres modifications. Je pensais que ce serait un bon moyen de faire en sorte que chaque entité possède son propre ObjectContext, de se joindre à ce ObjectContext et d'effectuer la transaction chaque fois qu'elle doit être sauvegardée.

Dans LINQ to SQL, DataContext est très léger et donc ma solution ne nécessite pas trop de mémoire et de performances. Est-ce la même chose avec ObjectContext?

Et l'attachement d'objets? Est-ce une lourde unité de travail comme LINQ to SQL ou pas?

Answer 1

Il a été soutenu que les objets ne devraient pas être être responsable de cela; leur travail consiste à représenter un objet instancié; c'est le travail d'une autre classe (référentiel) de le persister. ObjectContext peut être pénible lorsqu'il s'agit d'attacher/détacher des objets, car (contrairement à LINQ-to-SQL), il existe un couplage beaucoup plus étroit entre le contexte et l'entité. Personnellement, je n'utiliserais pas cette approche; J'utiliserais l'entité elle-même (ou une copie de travail) comme une unité de travail transitoire avec un contexte de courte durée.