Mon monde en .NET - LINQ - Commentaires2023-01-02T14:25:42+01:00Thierry Thouaurn:md5:feacb53e7f5d22db05e2d6025a495e81DotclearLINQ to SQL (detach / re attach dans un modèle N-tiers) - Thierry Thouaurn:md5:a0d37916aaadbb0f00ba6246986ad4542008-06-25T15:57:17+00:002008-06-25T15:57:39+00:00Thierry Thoua<p>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).</p>LINQ to SQL (detach / re attach dans un modèle N-tiers) - SuperDamzurn:md5:e95e1cff96a6c9ab9f69afd8999c3a022008-06-25T15:32:31+00:002008-06-25T15:32:31+00:00SuperDamz<p>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.<br />
Table.Attach(TEntity entity, TEntity original)<br />
Reste à déterminer l'original...</p>LINQ to SQL (detach / re attach dans un modèle N-tiers) - Stiiifffurn:md5:73afb1071e1247d19dcb1913776afbd82008-06-25T02:20:55+00:002008-06-25T02:20:55+00:00Stiiifff<p>Salut Titi,<br />
<br />
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.<br />
<br />
ç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.<br />
<br />
Le problème a 2 parties:<br />
- 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 !).<br />
- 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 ?<br />
<br />
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 !!!).<br />
<br />
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.<br />
(Il faut peut-être utiliser le Command pattern pour généraliser tout cela).<br />
</p>LINQ to SQL (locking) - Arrangeururn:md5:1f95ff09585498f06747cecfcdc92a4d2008-05-17T17:47:13+00:002008-05-20T20:17:43+00:00Arrangeur<p>un petit commentaire oour te dire qu'il est toujours plaiant de surfer sur tn blog ;)</p>LINQ to SQL (locking) - Thierry Thouaurn:md5:11218c01875fade5bf06bb31633471f62008-03-20T15:51:36+00:002008-03-20T15:51:36+00:00Thierry Thoua<p>
En effet, Entity Framework n'est pas qu'un ORM mais il se base sur Linq To SQL. Dès lors, il est intéressant de comprendre ce qui est généré en natif. Je pense honnêtement que la grande nouveauté des prochains mois sera ADO.Net Data Services pour les applications distribuées ... et la connaissance de Entity Framework et donc de Linq to SQL sera un plus non négligeable pour optimiser les développements. Après, on utilise toujours des "objets" ... Ceux-ci pourront toujours être généré via un autre ORM ... Après, il y a l'approche "gestion session/transaction" ... Abstraire cette partie serait en effet une bonne idée. Mais est-ce réellement indispensable ? ... Je ne pense pas que l'on change souvent d'orm en plein projet après validation de la structure de celui-ci ;-)
<br/>
PS: Mes statistiques ne sont pas prises en compte dans les historiques ;-).
</p>LINQ to SQL (locking) - Steve Degosserieurn:md5:c2eac9dce1ba0a703f7f00244741b9992008-03-20T13:17:21+00:002008-03-20T13:17:21+00:00Steve Degosserie<p>Le problème de Linq to SQL est que c'est un projet mort né. Microsoft a sorti Linq to SQL pour avoir un pied dans le monde des ORM (après leur débâcle avec 'ObjectSpaces'). Leur vrai projet, c'est Entity Framework (qui n'est pas qu'un ORM). Dès qu'il sera sorti, Microsoft ne parlera plus de Linq to SQL, qui est moins puissant, ne supporte qu'SqlServer.<br />
<br />
Donc, utiliser Linq To SQL aujourd'hui pour développer de réelles applications, oui, ça marche ... encore heureux, sinon il y aurait de quoi se poser des questions lol<br />
<br />
Par contre, je ferais attention de garder le modèle le plus indépendant possible (PI = Persistene Ignorance) de Linq to SQL, ce qui facilitera la migration vers Entity Framework quand cette techno sera prête (Microsoft proposera probablement des wizards de migration mais bon ... mieux vaut prévenir que guérir). Par précaution, je n'utiliserais pas non plus LtS pour de grosses applications critiques, mais uniquement pour de petites applications (front office).<br />
<br />
My 2 cents comme on dit ;o)<br />
<br />
PS : Elles sont marrantes tes stats sur les browsers et les OS :) plutôt inhabituelles ... j'en connais un qui n'utilise pas bcp Windows à la maison lol<br />
</p>LINQ to SQL (locking) - Thierry Thouaurn:md5:cceab0e2267b996cba424a3dc3ee9f5e2008-03-20T12:16:02+00:002008-03-20T12:18:30+00:00Thierry Thoua<p>Le ColumnAttribute est propre au système utilisé par LINQ to SQL pour le mapping... Dès lors ... certes en DDD ... il y a la possibilité d'avoir des limitations ... Mais aucun modèle n'est parfait et ActiveRecord utilise le même modèle pour déclarer certaines informations ;-). Pour ce qui est du champ nommé "IsVersion", il s'agit en effet d'une colonne dédié au versionning des tuples comme le fait NHibernate via le mapping <version>... J'ai oublié de le signaler ;-). Pour ce qui est du pessimitic ... il le supporte mais évidement comme toujours tu as actuellement les limitations de la base de données ... et le fait que Microsoft ne livre qu'une implémentation de LINQ to SQL pour SQL Server. Ce que je tente de mettre en évidence dans ce type de post est la possibilité de pouvoir développer une réelle application via Linq to SQL. Linq to SQL est très basique.... certes mais il sera suffisant pour plusieurs projets. Après avant de comparer NHibernate avec Linq , je pense qu'il faut attendre la sortie de Entity Framework qui lui est un réel ORM.<br/>
Pour ton projet OpenSource, cela m'interesse ;-).... <br/>
ps: N'oublie pas de faire un résumé sur ton blog des DSL =D.
</p>LINQ to SQL (locking) - Steve Degosserieurn:md5:95b269878d2df5efef4b41784e2361602008-03-20T09:42:10+00:002008-03-20T09:42:10+00:00Steve Degosserie<p>Salut Titi,<br />
<br />
Le fait de devoir mettre un attribut [ColumnAttribute] est assez 'invasif' dans ton modèle ... c'est flexible au niveau des fonctionnalités, mais pas au niveau de l'implémentation. Je t'invite à lire cet article qui évalue les possibilités de Linq to SQL par rapport à la 'Persistence Ignorance' (concept très important dans une architecture de type DDD):<br />
<a href="http://iancooper.spaces.live.com/blog/cns%21844BD2811F9ABE9C%21397.entry" title="http://iancooper.spaces.live.com/blog/cns%21844BD2811F9ABE9C%21397.entry" rel="nofollow" rel="ugc nofollow">iancooper.spaces.live.com...</a><br />
<br />
Aussi, j'ai découvert une propriété 'IsVersion' dans le [ColumnAttribute] ... on peut donc aussi faire de l'optimistic locking avec un champ version / timestamp.<br />
<br />
Je me mets en mode traducteur ...<br />
lock = verrou<br />
pessimistic locking = verrouillage pessimiste<br />
optimistic locking = verrouillage optimiste<br />
<br />
;o)<br />
<br />
Concernant le pessimistic locking, je ne serais pas surpris que cela ne soit pas supporté par Linq to SQL. NHibernate le supporte par contre.<br />
<br />
Il existe un troisième type de locking, qui est la fondation du DDD ... et que je n'ai pas encore vu appliqué et supporté dans un ORM standard : le Coarsed-Grained Locking :<br />
<br />
<a href="http://martinfowler.com/eaaCatalog/coarseGrainedLock.html" title="http://martinfowler.com/eaaCatalog/coarseGrainedLock.html" rel="nofollow" rel="ugc nofollow">martinfowler.com/eaaCatal...</a><br />
<br />
J'ai essayé de l'appliquer avec NHibernate mais ça ne marche malheureusement pas comme je le voudrais ... <br />
<br />
Si le DDD t'intéresse, je suis en train de réfléchir à la création d'un projet OpenSource pour construire une Software Factory pour le Domain Driven Design (il n'en existe pas vraiment à l'heure actuelle) ... et j'ai de bonnes idées ... :)<br />
<br />
(ton Captcha est chiant, il faut trop réfléchir lol)<br />
</p>Accès/modification de tuples en // sous Linq to SQL (lock ?) - Thierry Thouaurn:md5:80f3dc3f25c7122696b5e16ed08090912008-03-18T22:10:53+00:002008-03-18T22:10:53+00:00Thierry Thoua<p>Je suis 100% du même avis que toi Steve ... Mais la grande différence entre NHibernate et Linq to SQL est que LINQ sera supporté "nativement". Je m'explique ... Avec l'arrivée de ADO.NET DataServices, j'ai le sentiment qu'il sera bien plus aisé de faire une facade d'accès a la couche dao via LINQ to SQL que via NHibernate ... Après on en reviens au débat des DTO et des DAO qui seraient sérialisés et envoyés a l'ui etc ;-). NHibernate reste à mes yeux un super bel outil ... Mais LINQ to SQL a la facilité d'avoir des entités sérialisées "nativement" (en activant une option) etc. La sérialisation d'objets sous NHibernate est bien plus "complexe". Pour ce qui est du fonctionnement interne de LINQ to SQL... je comptais y regarder de plus près ce we ;-). La console de log ne m'a pas affiché de Select before update mais ... je pense que le mieux sera de tracer exactement les requêtes exécutées sur le serveur plutôt que de me fier à la console de log de Linq to SQL.</p>Accès/modification de tuples en // sous Linq to SQL (lock ?) - Stiiifffurn:md5:e355a6c994df10dc879326b9207fa1322008-03-18T09:19:39+00:002008-03-18T09:19:39+00:00Stiiifff<p>Tout ça ne nous dit pas comment cela fonctionne en interne ... ;o)<br />
<br />
NHibernate supporte à la fois les stratégies d'optimistic locking et de pessimistic locking ... cette deuxième catégorie est, en général, supportée par très peu d'ORM. Je pense d'ailleurs que Linq to SQL ne le permet pas.<br />
<br />
Reste à savoir, comment Linq to SQL gère-t-il l'optimistic locking:<br />
- Version / Timestamp<br />
- Select before update<br />
- Include modified columns in where clause<br />
- Include all columns in where clause<br />
<br />
Plus généralement, Linq to SQL doit avoir 5% des fontionnalités d'NHibernate. A utiliser pour un Domain Model simple et une DB SqlServer, ou du prototyping ... pas pour une vraie application ;o)<br />
</p>