Bonjour,

Je ne suis pas - encore - contributeur Jelix, mais il m'a semblé que ce forum était le plus approprié pour accueillir ce sujet.

Je résume le cheminement de ma pensée, n'hésitez pas à me corriger si besoin :

Jelix adopte le pattern DAO, qui fait également office d'ORM.

Il est fortement conseillé de ne pas manipuler directement les DAO à partir des contrôleurs mais plutôt d'utiliser une couche de services métiers supportée par jClasses.

En plus des ces "patterns" on utilise souvent le motif de conception Data Transfer Object (DTO) qui consiste, en gros, à élaborer un ensemble d'objets permettant de faire transiter les données entre la couche présentation et la couche service.

Bien que le pattern DTO ait d'abord été conçu pour répondre à une problématique de performance au sein d'une architecture distribuée, il offre également d'autres avantages qui peuvent être intéressants selon le contexte de l'application.

L'inconvénient majeur de cette pratique est le surcoût qu'elle engendre (développement, maintenance, assemblage des DTO, mapping avec les objets du domaine etc.).

Étant donné que les scripts Jelix permettent de générer pas mal d'éléments à partir de la base de données, ne serait-il pas intéressant de pouvoir générer également - si besoin - des DTO ?

Il s'agirait d'une génération "one shot", sous la forme de simples objets PHP (attributs, getters, setters) construits à partir des DAO. On pourrait choisir de générer ces objets ou non en ajoutant un argument aux commandes qui génèrent déjà des DAO par exemple.

Je pense qu'il faudrait creuser un peu pour trouver la bonne implémentation, mais déjà, dans un premier temps, est-ce que l'idée vous semble intéressante ?

Tu aurais un exemple (même grossier) de ce que tu veux obtenir exactement stp ? Car c'est un peu abstrait pour moi en tout cas.

Salut,

Ton objet DTO, ce ne serait pas le record DAO ? Parce que les objets record de jDao ne sont que de simple conteneur de données. Ce que tu proposes donc, ce serait de créer deux objets qui seront finalement identiques. À moins que je n'ai pas tout compris :-)

L'avantage du DTO c'est que tu peut y mettre a peut près n'importe quoi dedans et c'est justement pas lié a la couche donnés. Du coup je ne suis pas d'accord sur le fait que l'on doivent extraire ces DTO des informations saisies dans le dao.xml les records et les DTO sont deux choses distinctes. Ils ne servent qu'as établir la communication de services métiers au controlleurs, ou entre services métiers. Après c'est vrais que la notion de DTO/QO je ne l'ai vu qu'en Java, et que ça risque de complexifier un peu l'utilisation de Jelix d'implémenter les outils de création de DTO/QO.

Je dirais tout dépend des cas, les TO ne sont pas tout le temps intéressant a exploiter, j'ai déjà eu affaire a des cas ou on doit créer un DTO pour 4 informations a passer.. Par contre j'ai eu des cas ou il fallait passer des objets et des sous ensembles d'objet a un traitement, j'étais bien content a ce moment la de créer un DTO pour transférer tout ça.

Il faut comme Laurent l'as dit que Jelix reste simple c'est ce qui fait son charme et sa robustesse et qu'il reste suffisamment souple pour que les utilisateurs puissent l'étendre selon leur besoin. Et la c'est Laurent et les principaux contributeurs qui sont les chefs de la barque.

Je pense qu'il vaudrait mieux que tu regarde la manière dont son parsé les dao.xml par le framework.

Il y a mieux : on peut utiliser le jDaoParser, et ainsi avoir en retour toutes les infos dans des beaux objets ;-)

D'ailleurs, pour le ticket 871, je suis en train de remanier un peu jDao et jDbTools..