Discussion :

[camer12]

Salut

je n'arrive toujours pas à cerner la différence entre un Data Transfer Object et un Dataset. Je sais que les deux peuvent être utilisé pour transférer les donnée d' une base de donnée et une application. Dans mon Tool que je developpe actuellement j'utilise les dataSets(qui fonctionnent très bien) , je dois expliquer à mon Chef pourquoi j'ai choisi les DataSets et lui parler des autres possibilitées. Venez moi aide

[Sicyons]

Salut.

Je suis loin d'être un expert mais espère pouvoir éclairer ta lanterne. En fait les DTO (Objets de Transfert de Données) font partie d'un modèle de conception préconisé pour les applications pro faisant appel aux bases de données. Le modèle préconise de séparer la logique de l'appli en couches. Les DTO en sont une. Je vais prendre un exemple : une appli qui doit gérer des données d'employés.

1) L'appli fait appel aux Objets d'Accès aux Données (DAO) qui se chargent d'envoyer la bonne requête à la base pour obtenir les données voulues.
2) Les données obtenues (celles de l'employé recherché par exemple) sont stockées dans un objet d'une classe propre à l'appli que tu as créée pour ça : un DTO. Son rôle est UNIQUEMENT de stocker les données, sans aucune "intelligence" sous une forme qui correspond aux besoins métiers de l'appli (un objet représentant un employé dans notre cas, par exemple).
3) Le DTO est passé à des Business Objects (en français ça donne quoi ?), des objets dont le rôle est de traiter les données selon les règles métier (par exemple augmenter le salaire d'un employé, calculer ses congés restant, etc...).

Donc le DTO est un type d'objet que tu crées toi-même. Je ne pense donc pas que les DataSet puisse être considérés comme des DTO. Les deux ne sont donc pas en concurrence.

A première vue j'aurais tendance à dire que si l'on utilise directement les DataSets on s'affranchit de ce modèle de développement par couches en utilisant pas de DTO (on récupère les données brutes sous forme de DataTables ou DataSets sans avoir besoin de DTO pour stocker et organiser les données en leur donnant une structure calquée sur les règles métier du projet).

Pas certrain d'avoir été très clair sur ce coup-là .

[kheironn]

Les DataSet sont assez employés dans les applications en mode déconnecté. tu charges tes données dedans, tu les manipules et quand tu en as besoin tu pousses tes tables vers la base. Il faut être vigilent avec les accès concurentiels !

Le DTO sont des coquilles de données. Des objets stupides qui ne méritent pas leur nom d'objet (selon la définition POO), mais très apprécié pour le soi-disant découpage en couches.

Tu as la solution de faire des POCO (des objets avec données et méthodes) qui se situent alors dans ta BL. Ils appelent la couche DAL pour les transfert DB et sont utilisés pour les traitements. Il sont appelés par ta couche de présentation. Cette façon de faire n'est plus "à la mode", à tord du point de vue POO !
Mais, car il y a toujours un mais, si tu entre dans une problématique de traitement avec SGBD interchangeable (ce qui est rare) il devient difficile de la mettre en oeuvre. Si ton appli utilise sa propre DAL, sur un SGBD qui n'est pas destiné à changer, alors inutile de faire 2 dll pour la DAL et la BL (ça ne sert à rien) autant faire 2 répertoires et tu es débarassé de certains problèmes.
J'utilise assez souvant cete solution en intégrant une couche framework qui contient une classse générique pour l'ADO (avec gestion des connexions, requêtes, etc.) appelée dans ma DAL qui fait partie de ma DLL Core. ma dernière DLL étant la présentation qui peut changer. Mon "Core" est appelé par plusieurs projets et fonctionne très bien (factorisation + Design pattern à gogo)

[chrisdot]

C'est quoi comme appli ? Une appli lourde (WPF/Winform,...), web, client léger (silverlight)?
C'est en multi-tiers?

[camer12]

c'est une winForm

[chrisdot]

Et ma seconde question? (multi-tiers comment? winform => BDD ou Winform => svc =>BDD)?

[camer12]

Elle n'est pas en multi-tiers

[chrisdot]

Bin alors ta répose est simple:

Elle n'est pas en multi-tiers

=> donc pas besoin de tranporter les données
=> donc pas besoin de DTO (T = transfert)

Donc un dataset va très bien dans ton cas, car tu n'as aucun besoin de le trasnporter dans un service WCF par exemple. (Car un dataset est un objet assez lourd à transporter, et je sais même pas si c'est possible car sans doute plein de dépendances)

[camer12]

est il néanmoins possible d'utiliser les DTOs dans les applications non multi-tiers?

[Bluedeep]

est il néanmoins possible d'utiliser les DTOs dans les applications non multi-tiers?

Absolument.

[chrisdot]

est il néanmoins possible d'utiliser les DTOs dans les applications non multi-tiers?

Bien sûr mais où est l'intérêt?

[camer12]

Une autre question: Pourquoi le datagridview est il plus approprié(d'après ce que j'ai lu sur le net) que les autres contrôleur en ce qui concerne le "binding" avec le dataset. Pourquoi pas Treeview ou Listview......

[Bluedeep]

Une autre question: Pourquoi le datagridview est il plus approprié(d'après ce que j'ai lu sur le net) que les autres contrôleur en ce qui concerne le "binding" avec le dataset. Pourquoi pas Treeview ou Listview......

Cela dépend du type d'interaction utilisateur dont tu as besoin : TreeView et ListView ne sont destinés de facto qu'à de l'affichage. Le DataGridView permet la saisie.