Discussion :

[CIFQ_Drew]

Bonjour,

Depuis longtemps j'utilise différentes implémentation plus ou moins bricolé du pattern DAO, principalement inspiré de ce site. J'ai réalisé ce pattern en Java, PHP, C++ et C# mais avec très peu de rigueur.

Ma dernière expérience fut en C#, dans le cadre d'un petit projet (~10K de code). Nous avions une contrainte particulière sur la source de données, qui pouvait osciller entre SQL Server 2000, 2005 ou 2008, ou encore Access 2002-2003 ou Access 2007 et MySQL 5.

J'ai donc débuter mes travaux et voici ce que j'en ai tirée :

• BusinessObject : Objet métier, qui correspond par exemple à un utilisateur, un compte bancaire, etc ;
• DataSource : C'est ma source de données, qui envoie les requêtes a celle-ci ;
• DataAccessObject : Avec l'aide d'un DataSource, permet la gestion complète d'un type de BusinessObject.

Mais dans le liens que je vous ai envoyer, il y a un petit mouton noir : le TransfertObject. Mais kesako ?!?

Je ne sais pas dans quel angle voir la chose : voici ce que je crois comprendre :

1. Mes classes dérivant de DataAccessObject et DataSource ont prit la responsabilité qu'aurait du prendre TransfertObject ;
2. Mon DataAccessObject devrait utilisé un TransfertObject pour envoyer les données vers le DataSource ;
3. Je suis à coté du sentier et l'analyse n'est pas mon domaine

Je vous remercie d'avance de votre aide,

Drew

[ego]

Les DTO sont les objets qui transitent entre la couche IHM et la couche métier dans le cas d'architectures distribuées (le tier IHM n'est pas sur le tier métier).

Les DTO sont donc des "bouts" de tes BusinessObjects = les bouts dont l'IHM a besoin pour faire ce qu'elle a à faire. Dit d'une autre manière, les services métiers qui sont offerts à l'IHM et aux autres applications aussi si ton application peut être appelée par d'autres applications, ont des paramètres en entrée/sortie typés avec des DTO.
Tu peux aussi faire le parallèle entre DTO et vues côtés bases de données. Les BusinessObject sont les Tables, les DTO des Vues. Les DTO contiennent des attributs provenant directementdes BusinessObjects mais aussi, si besoin, des données calculées.

Quand un service récupère en entrée un ou plusieurs DTO, son premier job est de récupérer le ou les BusinessObjects (BO) correspondant puis de transféréer les données du DTO dans les BO, ceci en s'appuyant sur tes DAO. Ensuite, ils (les services) exécutent la logique métier en travaillant toujours sur les BO, pas avec les DTO qui ne sont que des objets de transfert.
Si tu dois retourner des infos, ton service créera un ou plusieurs DTO à partir des BO.

Si tu veux plus de précisions, n'hésites pas