Discussion :

[Henry9]

Bonjour,

j'essaye de créer mon application winform avec une architecture multi couche, ma question est comment faîtes vous dans votre couche business pour appliquer des logiques métiers à vos objets représentant votre modèle de données ? Est-ce que vous utilisez les entités générées par Linq to sql ? ou alors vous créez vos propres business objects ? Dans ce dernier cas, je trouve que c'est redondant et fastidieux de recréer les même champs que les entitées Linq, est-ce normal ?

Et deuxième question, comment faîtes vous si on veut récupérer les données d'une requête sql qui joint deux tables ? on recrée un business object avec les champs des deux tables réunies ?

Merci d'avance.

[Skyounet]

Pour ta première question, pour ma part je réutilise les objets crées par Linq2Sql dans ma couche métier.

Tu trouvera sur le forum d'autre pattern plus ou moins compliqués.

Il me semble que Entity Framework est plus adapté pour les architectures multi-couches.

[Bluedeep]

Pour ma part, j'ai précisément éliminé Linq to Sql à cause des difficultés qu'il engendrait avec les architectures n-layer, difficultés amplifiées encore avec le n-tier.

Si je n'utilise pas EF, je n'utilise que l'accés au proc stoc de Linq To Sql; c'est le seul cas où je trouve le rapport cout/benefice intéressant (check des paramètres à la compilation), encore qu'il soit incapable de regrouper ces typages de retour entre deux proc stoc qui retourne le même type de donnée !!!!

MS semble clairement ne plus capitaliser sur Linq To Sql, et ça se comprend.

[Henry9]

Skyounet, éventuellement si tu as des noms de patterns en tête, indique les ici. J'avais lu dans un article que le pattern repository serait adapté, faut que je la retrouve.

Je vais étudier des orm alternatives pour voir ce qui se fait ailleurs mais bon, j'aimerai bien garder linq 2 sql pour sa simplicité et réussir à avoir une architecture propre avec.

Bluedeep, merci pour ton témoignage, et à titre de curiosité, peux tu juste indiquer quel orm tu utilises ?
Concernant le typage de tes proc stoc, tu peux essayé de les typer avec un POCO.

[amadray]

Bonjour,
il faut noter que Microsoft a arrêté le "développement" de LinqToSQL, et qu'il est préconisé d'utiliser LinqToEntities. Cependant LinqToSQL fonctionne et continuera à être supporté.
Le passage de l'un a l'autre est très facile (les syntaxes Linq étant identiques).
Personnellement j'utilise donc LinqToEntities pour générer la DAL et l'aspect ORM, en surchargeant à l'aide de classe partielle les entitées générées pour incorporer la logique métier. Tout ça dans un projet de type DLL, qui sera utilisé par des projets WinForm, ASP.NET, ou encore Silverlight.

Cordialement,
A.M.

[Skyounet]

ou encore Silverlight.

Euh je pense pas pour Silverlight, vu que SL ne gère pas ces choses là (sauf en passant par un WS).

[Henry9]

Bonjour,
il faut noter que Microsoft a arrêté le "développement" de LinqToSQL, et qu'il est préconisé d'utiliser LinqToEntities. Cependant LinqToSQL fonctionne et continuera à être supporté.
Le passage de l'un a l'autre est très facile (les syntaxes Linq étant identiques).
Personnellement j'utilise donc LinqToEntities pour générer la DAL et l'aspect ORM, en surchargeant à l'aide de classe partielle les entitées générées pour incorporer la logique métier. Tout ça dans un projet de type DLL, qui sera utilisé par des projets WinForm, ASP.NET, ou encore Silverlight.

Cordialement,
A.M.

Le surcharge à l'aide de classe partielle, tu peux également le faire avec linq 2 sql. Je ne connais pas encore très bien linq 2 entities, mais comment fais tu pour passer les valeurs des textbox de ton UI dans ta DLL ? tu utilises les objets métiers généré par LinqToEntities ?