Discussion :

[cobolfingaz]

Bonjour à tous,

Comme je ne me servais d'aucun ORM pour mon projet que j'ai codé moi-même le mapping, je me suis intéressé à Linq To Sql, qui accélère de beaucoup la création des entitées et des opérations CRUD.

J'ai donc détruit ma couche d'accès aux données et créé une class library à part, qui contient mon .dbml.

On conseille de séparer la couche d'accès aux données et la couche de présentation par une couche "business" qui elle appelle les fonctions de la couche d'accès aux données pour retourner les entités ou les collections d'entités nécessaires à la couche présentation.

Le problème que je vois avec Linq To Sql, est que mes entités font partie du fichier .dbml, donc si je veux accéder à ces entités par ma class library de présentation, je dois faire un lien direct entre cette dernière et la class library d'accès aux données.

Je ne pense pas que ce soit une bonne idée de "hardcoder" des expressions DLINQ directement dans mes interfaces utilisateur, alors, dans ma class library d'accès aux données (qui contient le fichier .dbml), j'ai créé une helper class qui contient les fonctions concrètes à ce que mes interfaces ont besoin (GetEmployee(int id), GetEmployees(), etc.). Ça centralise les fonctions d'accès aux données, mais j'ai quand même un lien direct entre ma couche présentation et ma couche d'accès aux données.

De plus, et c'est ma question principale, les fonctions qui ajoutent de nouvelles entités à la base de données via mes interfaces (AddEmployee(...)) contiendraient trop de paramètres, car je dois spécifier une tonne d'information pour l'entité. J'aimerais donc pouvoir, de mon interface, quand l'utilisateur clique 'OK', d'instancier une entité Employee, et d'assigner chacune de ses propriétés aux valeurs des textbox et combobox. Encore là, un lien direct avec ma couche d'accès aux données car je me sers des entités du fichier .dbml directement via ma methode cmdOK.Click();

Est-ce que quelqu'un a suffisamment travaillé avec Linq To Sql pour me guider vers une structure qui se tienne ?

Merci d'avance pour vos suggestions !

[dinbougre]

Juste une information, Microsoft semble conseiller d'utiliser entity framework au maximum aujourd'hui à la place de Linq To Sql. Enfin c'est ce que j'ai cru comprendre en lisant les différentes news par ci par là.
Linq To Sql ne va pas disparaitre, mais ne sera plus (ou que très peu) mis à jour (autant dire qu'il va mourir tout seul).

[The_badger_man]

Les entités Linq to SQL ne sont pas tes objets métiers. C'est une couche d'abstraction de la base de données, pas de ton domaine. C'est là où se situe la confusion.
C'est un peu l'équivalent des DataSet.

[Paul Musso]

Bonjour,

Pour un meilleur design, tu peux mettre tes fonctions GetEmployee(int id), GetEmployees(), AddEmployee dans une dll à part appelée Business par exemple. C'est ta BLL. Celle-ci fait référence à ta librairie contenant ton fichier DBML. La librairie Business est ensuite référencée par ta couche présentation.

Pour que ta couche présentation ne soit pas couplée aux classes d'accès aux données, alors les fonctions de ta BLL ne doivent pas renvoyer ou prendre en paramètre des objets définis dans la DAL. Il faudrait en recréer de nouveaux dans ta BLL. Ceci dit, ils seraient casi identiques à ceux de ta DAL.

LinQ to SQL ne permet qu'un mapping fortement couplé à la BDD du style une entité = une table. Au mieux on peut faire : une hiérarchie d'entité = une table (avec l'héritage). De plus, si tu remarques bien, les classes générées par le designer DBML contiennent des attributs faisant référence à des noms de tables et de colonnes. Tu pourrais arranger cette dépendance en utilisant SQLMetal et les options qui vont bien pour utiliser un fichier XML où sont définis les informations de mapping.

Comme dit dinbougre, Entity Framework est une bien meilleure solution, car les objets métiers générés ne sont pas couplés à la structure de la base de données.

[cobolfingaz]

Merci !