Discussion :

[Philippe Vialatte]

Bonsoir a tous...

suite a un début de conversation dans le forum (et pour éviter de ne jamais pouvoir voir la suite de celle-ci, vu le rythme effrene...), j'ai eu (enfin) l'occasion de mettre en place un VS 2008 au travail (il était temps ), et la première chose a été de prendre 2 pauses repas pour essayer de démêler un peu Linq To SQL...et essayer d'en sortir un machin sympa...en gros, un portage d'appli non vitale

Au bout du compte, je suis arrive a l'archi provisoire suivante :

DTO : couche d'objets de transfert de données : mes objets c# classiques (Article, client, etc...), decores des atributs qui vont bien pour les passer a un service wcf
Repository : couche d'accés aux données : le dbml, une interface IRepository, une implementation LinqRepository. Les fonctons du repository remplissent des objets de DTO, et les renvoient soit sous forme d'objets tout seuls, soit sous forme d'Iqueryable<dto.objet>
Service : dans l'appli sur laquelle je teste, on a deux clients legers en winform, et un client java -> partie "business" et service WCF (en plus, c'est buzzword compliant, service, avec SOA )
Client : mon client (pour le moment, une console).


Qu'est-ce que vous en pensez ?

Est-ce que je me plante grave ?

Est-ce que ca vaut le coup de développer plus (article/tuto...voire a plusieurs mains, si certains se sentent ?)

Ce qui me gene avec l'approche Linq To Sql, c'est l'omnipresence du contexte...cette organisation a l'avantage de confiner le contexte dans une seule couche, et de rendre les clients completement ignorants du systeme de persistance...mais est-ce que ca vaut le coup (rhétorique, pour moi, ça le vaut )

[SaumonAgile]

Ton approche ne me choque pas. Je ne vois pas d'inconvénients majeurs.

Personnellement, j'ai un dbml dans la DAL qui génère les entités dans le namespace entities, et le context dans le namespace DAL.
Le context a une portée internal.
La couche business est dans la même assembly et s'appuie sur le context en passant par un factory pour renvoyer des collections d'objets et/ou des objets simples.
Les services utilisent la couche business et ne sont presque que des facades. Je postsharp la gestion d'exceptions dans le service pour la gestion des Fault et la validation (enterprise library contrib) dans le business.
Tout ça multiplié par n services pour former un nuage de services (aka SOA).

Les applis clientes piochent dans les services WCF les "services" (au sens conceptuel) dont elles ont besoin.

[zoubidaman]

Je ressors un peu le topic, mais je me pose une question sur la gestion des exceptions lancées par LINQ.

Par exemple, LINQ lance une SqlException en cas d'insertion d'une valeur nulle sur un champ qui ne peut pas l'être, ou en cas de rupture de la clé d'unicité. Il lance une ArgumentNullException quand on tente d'ajouter un objet qui est null.

Est-ce que vous laissez ces exceptions se lancer pour les capturer dans la DAL ou la BLL?
Ou bien est-ce que vous controllez avant l'insertion que tout va bien se passer et lancez vous-même vos exceptions si vous avez détecté avant coup qu'il va y avoir un problème?

J'imagine que selon l'application ça peut varier, mais vous faites comment vous?