Discussion :

[Muller Guy]

Bonjour,
J'utilise depuis peu linq to sql et je trouve cela génial.

Avec une seule table, je n'ai pas de difficulté, mais avec ue vue ou une jointure, je ne peux pas mettre à jour mes données, malgré la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SubmitChanges()

je n'ai pas de messages d'erreur.

J'ai le même problème avec des procédures stockées.

Avez-vous une piste, faut-il donner un statut particulier à la vue ?

Merci d'avance.
Muller Guy

[bakonu]

Bonjour,

Si tu dois faire une jointure, fais la dans ton programme, entre les objets, sinon c'est normal que tu ne puisses pas modifier les données d'une vue ou d'une jointure.

[anthyme]

Arreter d'utiliser linq to SQL qui est une technologie obsolète ?

Entity Framework est sortie il y a maintenant 2 ans et c'est la technologie d'accès aux données mis en avant par Microsoft, qui évolue et évolura dans l'avenir ...

[cinemania]

En réalité Linq To SQL était un avant projet de ce qu'est Entity Framework et tout particulièrement Linq To Entities.

Le but était là de poser les fondations et fondements pour EF, et donc de proposer une première transition entre l'ancien modèle ADO.NET et celui basé sur EF.

A priori je dirais qu'il est préférable de passer à Entity Framework pour diverses raisons, et pas uniquement parce que c'est la technologie mise en avant par microsoft.
Regarde le code généré par les outils pour ton Linq To SQL. Tu y vois que les objets reflétés sont loin d'être propre... en effet, le code linq to sql ne respecte pas les règles de séparation des couches et des responsabilités et on trouve de la logique dans les objets métiers...
Si tu tiens à faire une architecture totalement découplée ou chacun reste chez soit pour bien dissocier les responsabilité, Linq To SQL est clairement à proscrire.
Ensuite effectivement, cette technologie n'évoluera plus, et n'a finalement été comme déjà dit auparavant qu'un passage rapide mais obligé pour changer un peu les mentalités.
Ensuite viennent des raisons encore plus intéressantes, le mapping O/R est contrôlable parfaitement avec EF mais pas avec Linq To SQL...
dans lqts une table = une classe... c'est une contrainte.
dans EF tu fait ce que tu veux, on sais que certaines tables n'ont pas lieux d'être sous formes de classes, et tu peux dans EF ne pas les faire refléter directement comme des classes et ne les utiliser finalement que du côté SQL.

En réalité, EF permet de s'abstenir de passer par un framework tiers genre NHibernate pour le mapping O/R. remarque on pouvait toujours s'en passer, certes, mais là c'est nettement plus flagrant.

Sinon pour répondre à ta question, il est impossible en Linq To SQL de faire des changements et de les rendres persistants directement sur une vue/jointure. C'est encore une des limitations technique de LtS. Cela dit avant de s'enflammer, modifier le résultat d'une jointure avec LtE mène au même résultat, et c'est finalement assez logique.