- Gestion du versonning des tuples Il est indispensable d'avoir un système de versionning de tuple pour vérifier que l'objet a des modifications // aux données en base de données. Il suffit d'ajouter un champ "timestamp" en DB et de positionner les options comme ci-dessous.
- Méthode Detach sur l'entité Bizarrement, cette méthode n'existe plus (elle était disponible dans certaines bêta :/) dans le code généré. Il est cependant possible de l'implémenter à la main.
public partial class Bill
{
public void Detach()
{
this.PropertyChanged = null;
this.PropertyChanging = null;
this.BillItems = default(EntitySet);
}
}
TestDataContext context = new TestDataContext();Quid de Entity Framework ?
Bill cust = context.Bills.Single(c => c.Id == 1);
context = null;
cust.Name = DateTime.Now.ToShortTimeString();
cust.Detach();
TestDataContext context2 = new TestDataContext();
context2.Bills.Attach(cust, true);
context2.SubmitChanges();
Je vous conseille ce lien pour répondre à une partie de cette question.
3 réactions
1 De Stiiifff - 25/06/2008, 02:20
Salut Titi,
Malheureusement, ce n'est pas aussi simple que ça. Le scénario que tu décris n'est pas supporté par Linq to Sql ... et, ce qui sera peut-être un autre scoop, n'est pas non plus supporté (ou à moitié) par NHibernate.
ça marche peut-etre avec une entité hyper simple qui n'a pas de child ... mais dès que tu essaies avec une entité complexe, ça foire.
Le problème a 2 parties:
- Gestion de l'état : comment ton ORM peut savoir ce qui est modifié dans ton entité, une fois celle-ci détachée du contexte, alors qu'elle ne garde pas d'état (elle a seulement un état 'current' dont on ne sait rien !).
- Gestion du Lazy-Loading : qui du Lazy-Loading une fois l'entité détachée, ou ré-attachée à un nouveau contexte ? que se passe-t-il si je veux rajouter une nouvelle ligne de facture dans mon entité détachée ?
En fait, c'est une problématique bien plus large : il ne faut pas distribuer ses entités (M. Fowler's First law of Distributed Computing : Don't distribubte your objects !!!).
Il faut donc penser en terme de messages: Les changements qui se produisent côté client doivent être 'rejoués' côté serveur sur des entités reloadées de la DB ... c tout de suite moins facile qu'utiliser l'entité de bout en bout.
(Il faut peut-être utiliser le Command pattern pour généraliser tout cela).
2 De SuperDamz - 25/06/2008, 15:32
En effet la gestion de l'état peut poser problème... A moins de préciser quel est l'état à considérer comme "initial" lorsque l'on s'attache au nouveau contexte.
Table.Attach(TEntity entity, TEntity original)
Reste à déterminer l'original...
3 De Thierry Thoua - 25/06/2008, 15:57
Il est indispensable d'utiliser des DTO .. ;). Après pour NHibernate, il y a la possibilité de "SaveOrUpdateCopy" ... Mais en effet, il est impossible d'utiliser la méthode Delete avec un objet détaché. Je suis néanmoins déçu de Entity Framework ... je m'attend à beaucoup plus d'un ORM ... (mais ca semble être le sentiment de beaucoup de personnes au vu de la lettre ouverte visible sur le net).