[Débat] Linq to SQL VS Framework Entites

Bonjour,

Je crée ce topic pour lancer un débats sur ces deux technologies d'accès aux données.

Plus que pour voir les 2 scores, c'est plutôt pour avoir une oppositions d'idées argumentée et intéressante pour ceux qui ne connaissent pas ces technos.

Personnellement j'ai travaillé sur linq to sql et légèrement testé EF et donc voici mon avis :

Avantage a Linq to SQL (LTS) :
- Capacité a générer la base de données a partir du mapping ce qui permet de tout faire dans visual studio (EF ne peut que générer le mapping a partir de la base)
- Légèreté de la configuration (EF et ses 3 fichier de mapping arrive a rendre lourd le parametrage même avec un bon GUI...)
- API plus générique permettant de créer des BBL/DAL/... generique (l'api d'EF se base trop sur les valeur string des type plutot que sur les type CLR)
- Meilleur gestion des POCO

Avantage a EF
- Meilleur gestion des relations m to m (quoi que avec linq cela ne change pas grand chose en LTS)
- Meilleur gestion des applications ntier (plus de possibilités pour attacher et détacher les objets)
- Meilleur gestion de l'héritage (LTS peut uniquement faire de l'héritage dans une seul table)
- Meilleur support par microsoft (et oué MS sais plus quoi faire LTS et EF est taillé pour l'avenir)

Voila perso je suis un peu deçu de EF v1 (surtout pour la génération de la base que nhibernate fait depuis des années ou encore le manque de généricité comparé a LTS qui le fait tres bien) donc je vote LTS mais je pense que l'avenir sera a EF ...

j'attends impatiemment la v2 car LTS est un peu léger pour les grosses appli d'entreprise (dés qu'on fait du ntier) et si ça me plait pas je me pencherai surement plsu sur nhibernate (si je l'ai pas fait avant)

A vos claviers ;)

Pour moi c'est "autre".

LTS : Pas de sérialisation des entités liées en WCF.
EF : Les entités ne sont jamais vraiment déconnectées de la source. C'est bon pour les applis orientées données, pas pour les applis orientées objets (valable aussi pour LTS d'ailleurs).

Je serais plutôt sur de la génération de code, même si je suis toujours à la recherche d'un (ou plusieurs) modèle d'architecture robuste et évolutif. :)

Citation:

---

Envoyé par SaumonAgile

LTS : Pas de sérialisation des entités liées en WCF.

---

Juste une petite remarque : c'est faisable, y a quelques techniques :

Déjà ne pas marquer le context en "serialisation unidirectionnal" ensuite 3 techniques :
- copier coller les classes générés dans le fichier designer.cs et lui mettre les Datamember à la main (bof)
- Laisser WCF (requiert 3.5 SP1) sérialiser les objets tel quel en faisant attention au cycle dans la serialisation de graphes d'objet :
+ Soit utiliser un serialiseur spécial évitant les cycles dans les graphes d'objets
+ Soit marquer les champs non désiré de l'accesseur "internal"

Plutôt EF pour moi... en fait j'élimine d'office Linq to SQL parce qu'il ne supporte que SQL Server, et je trouve ça totalement inacceptable :evilred:

De plus, j'aime bien, dans EF, la séparation du modèle conceptuel et du modèle physique de données, qui permet de manipuler les entités de façon plus intuitive.

Après, c'est vrai que EF est nettement plus complexe, surtout quand on fait le mapping d'une BDD qui n'implémente pas les clés étrangères (SQLite en l'occurence). J'ai mis un bon moment à comprendre le principe, et je suis pas encore sûr d'avoir tout saisi.

Par contre j'ai une petite déception vis-à-vis d'EF... c'était peut-être un peu naïf, mais je pensais qu'on pourrait l'utiliser avec n'importe quel provider ADO.NET existant, sans modification du provider... en fait ça demande apparemment quelques adaptations, pas encore supportées par la plupart des providers (mais c'est déjà bien avancé pour SQLite :))