Linq VS Diagramme de classe?

**nasimpat7** · 28/03/2010, 14h19

Bonjour à tous,

Je viens vers vous pour recueillir vos avis sur quelques questions qui me taraude.

Je suis actuellement étudiant et dans le cadre d'un projet de groupe, je dois faire un travail de conception sur une application web.
J'ai pensé faire de l'UML, plus précisemment un diagram de class pour bien concevoir orienté objet.
La technologie utilisée pour cette application sera de l'ASP.NET / C#, et les questions que je me pose sont les suivantes:
Est-ce qu'il est possible de passer d'un diagram de classe vers Linq?
Ne serait-il pas mieux d'utilisé directement la techonologie Linq?
C'est à dire: modéliser et créer directement la base de données, et de passer par Linq pour la créer les class dans le projet.
Ou encore ne serait-il pas mieux de ne pas utiliser Linq et générer un squelette à partir d'un diagram de class?

Merci d'avance pour vos avis.

**cybermaxs** · 29/03/2010, 11h29

Salut,

Je pense que ton raisonnement n'est pas adaptée au génie logiciel. UML est LA méthode modélisation la plus connue et utilisée de nos jours. C'est indépendant de la technologie. Cette étape de modélisation est extrêmement importante dans un projet même si paradoxalement c'est souvent celle la plus bâclée.

Tu proposes de partir vers l'outil de conception d'une famille d'une technologie. Au-delà de l'aspect très très spécifique de ce choix, il faut regarder du coté des limites actuelles de cette technologie. Le projet Linq To Sql bien que fonctionnel n'évoluera plus. Le concepteur de Linq te permet de générer des classes typées pour Linq en fonction d'une base, mais pas de faire de la modélisation.

Autre problème, le mise en place du modèle avec Linq va impacter la conception de ta base. En général, il faut faire l'inverse : définir convenablement le MCD (puis le MPD). Si ta base n'est pas bien conçue, ton application en subira les conséquences ...

Ce n'est que mon avis ...

**oyigit** · 29/03/2010, 12h37

Il y a dans ton intérpretation de Linq une confusion. Linq est un composant qui te permet d'interroger une source de données (base de données, répertoires, fichiers xml...). Tu peux rendre n'importe quelle objet de ta classe maniable par Linq, en implémentant l'interface IQueryable. En revanche, l'Entity Framework est fait pour interroger une base de données. Il permet de générer une source IQueryable, donc attaquable via des requête Linq.

Pour en revenir à la conception de ton diagramme. Pour moi, il est évident de concevoir en amont sa base (MCD -> MPD). l'Entity Framework va permettre de générer tes classes (tu auras en quelques sorte un diagramme de classe en C#). Il faut savoir que ce diagramme est largement calqué sur ton MPD. Il est plutôt complexe de se détacher de ton modèle physique (hormis les trois ou quatres cas courant proposé dans les Web Cast Microsof). Aussi, il faut savoir que le designer VS ne supporte pas toutes les fonctionnalités de l'EF.

**cybermaxs** · 29/03/2010, 12h46

Envoyé par oyigit

Il y a dans ton intérpretation de Linq une confusion. Linq est un composant qui te permet d'interroger une source de données (base de données, répertoires, fichiers xml...). Tu peux rendre n'importe quelle objet de ta classe maniable par Linq, en implémentant l'interface IQueryable. En revanche, l'Entity Framework est fait pour interroger une base de données. Il permet de générer une source IQueryable, donc attaquable via des requête Linq.

Le projet LinqToSql permet d'interroger une base. Mais c'est encore un argument qui ne va pas dans le sens de nasimpat7 : pouquoi Linq et pas Entity ? Normalement ni l'un ni l'autre c'est un choix de modélisation qui impacte fortement la réalisation technique.

**oyigit** · 29/03/2010, 12h58

Envoyé par cybermaxs

Le projet LinqToSql permet d'interroger une base

Oui, mais encore une fois, linq n'est pas linqtosql ( ni l'entity framework d'ailleurs). linq est un moyen (langage unifier) d'interroger une source de données (quel que soit la source qui implémente IQueryable), linqtosql permet de te générer une source données IQueryable (et gère aussi d'autre aspect comme la relation entre les objets...)

**cybermaxs** · 29/03/2010, 13h03

Envoyé par oyigit

Code :

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

Le projet LinqToSql permet d'interroger une base

Oui, mais encore une fois, linq n'est pas linqtosql ( ni l'entity framework d'ailleurs). linq est un moyen (langage unifier) d'interroger une source de données (quel que soit la source qui implémente IQueryable), linqtosql permet de te générer une source données IQueryable (et gère aussi d'autre aspect comme la relation entre les objets...)

Oui bien sûr. Mais ne jouons pas sur les mots. Son post fait manifestement référence à LinqToSql, sinon ... j'ose pas imaginer

**oyigit** · 29/03/2010, 13h09

Envoyé par cybermaxs

Mais ne jouons pas sur les mots

C pas le but ! je dit simplement ça parce que même dans le monde professionnel, l'amalgame est encore fait. Bcp de développeur .Net (en tout cas dans ma société), n'ont pas encore le relfèxe d'utiliser linq pour interroger une liste d'objets en mémoire.

Pour en revenir au problème, ni l'EF n'est pas adapté pour la génération de diagramme (trop de lacune pour personnaliser le modèle). Linq to sql est encore pire, car bcp plus rattaché à la BDD que linq to sql...

**nasimpat7** · 30/03/2010, 00h43

Bonjour et merci pour vos réponses!

Ce qui est important pour moi c'est l'architecture et le respect du modèle objet. Ma vision est peut être fausse mais la modèlisation d'une appli ou d'une BDD doivent à mon sens être proche.

LinqToSql fait le lien rapidement, mais est-ce qu'au niveau de l'appli le modèle objet est vraiment respecté!

Oui bien sûr. Mais ne jouons pas sur les mots. Son post fait manifestement référence à LinqToSql, sinon ... j'ose pas imaginer

En effet, je faisais bien référence à du LinqToSql qui génére des class partielles en fonction d'une base de données.

Oui, mais encore une fois, linq n'est pas linqtosql ( ni l'entity framework d'ailleurs). linq est un moyen (langage unifier) d'interroger une source de données (quel que soit la source qui implémente IQueryable), linqtosql permet de te générer une source données IQueryable (et gère aussi d'autre aspect comme la relation entre les objets...)

Si je comprend bien, en faisant mes propres class qui implente IQueryable je pourrais faire du linq. Mais y a aura t-il un lien avec la BDD?

Je crois qu'il serait mieux de générer son propre code à partir d'un bon diagram UML et faire du Linq qui est très proche de l'objet.

Enfin bon, je reste encore confu.

Si vous pouviez m'apporter d'autres avis et conseils, je suis preneur.

Merci par avance.

**nasimpat7** · 30/03/2010, 10h23

En regardant un peu ce qu'était ADO.NET Entity Framework, je crois que j'ai trouver ce que je cherchais.

Entity Framework présentent quelques avantages non négligeablent:
http://msdn.microsoft.com/fr-fr/library/bb399572.aspx

Notamment de pouvoir implémenter un modèle complexe avec des notions d'héritage etc.., la prise en charge de Linq.

Il faut que j'approfondisse cette piste et voir comment on utilise cette technologie.

Si vous avez d'autres pistes n'hésiter pas.

**oyigit** · 30/03/2010, 12h23

Effectivement, je pense que l'Entity Framework répond plus à ton besoin que LinqToSql. C'est un moyen rapide est assez efficace (je pense) de gérer une BDD dans ton appli. En revanche, en terme de conception, tu risque de tomber sur pas mal de contrainte, et je pense que tu auras besoin d'adapter ton modèle UML en fonction des contraintes imposées par l'EF, ce qui en soit, est un des plus gros défaut de l'EF.

**nasimpat7** · 30/03/2010, 16h28

Pouvez-vous me conseiller un bon livre sur l'Entity Framework?
Je n'est pas trouvé de Post sur le forum dédié à ce sujet.

Merci par avance.

**oyigit** · 30/03/2010, 16h39

Désolé, me suis toujours débrouiller sur le net. En revanche j'avais acheté dans le temps un bouquin sur C# de chez Eyrolles, en général je trouve leur bouquin plutôt bien fait (sans vouloir faire de pub). Ils doivent bien avoir un truc sur l'EF. Pis si t'a des questions, y'aura toujours quelques geek ici pour répondre

**cybermaxs** · 30/03/2010, 17h03

Envoyé par nasimpat7

En regardant un peu ce qu'était ADO.NET Entity Framework, je crois que j'ai trouver ce que je cherchais.

Entity Framework présentent quelques avantages non négligeablent:
http://msdn.microsoft.com/fr-fr/library/bb399572.aspx

Notamment de pouvoir implémenter un modèle complexe avec des notions d'héritage etc.., la prise en charge de Linq.

Il faut que j'approfondisse cette piste et voir comment on utilise cette technologie.

Si vous avez d'autres pistes n'hésiter pas.

Sans vouloir insister ni passer pour un réfractaire, je pense que tu réalises encore un raccourci trop rapide. L'EF, même en V4, et comme tout ORM, vis très mal sa vie en dehors de la base de données. Tu verras sur le net, des tas d'exemples où des développeurs n'arrivent pas à maintenir le modèle de l'EF sans faire un RAZ puis ré-import total de la base. Je n'ai pas suffisamment de vécu dessus pour te le confirmer. A la différence de LINQ, tu ne peux pas créer une base avec EF. Tu devras nécessairement passer par une phase de conception de ta base. Qui sera faite avec quoi ? UML ?

Pour en finir sur une note optimiste, et revenir sur un post initial, si tu as besoin d'une conception rapide, et que ton projet est de faible ampleur, il est pertinent d'utiliser EF pour sa rapidité de mise en place.

Il faudrait suggérer l'avis des experts sur EF...