Débat sur la conception d'une application CRUD

Bonjour à tous,

Cela fait maintenant un petit moment que je programme en Java et j'aimerais confronter vos idées à propos d'un possible "best practice" dans le cadre de la conception d'une application de type CRUD, et, plus particulièrement, de la pertinence de l'utilisation du pattern DTO.

Je souhaiterais exposer différentes architectures et je vous propose de choisir le modèle que vous préfèrerez. Je rappelle que les architectures fictives sont développées avec les dernières API J2EE6 (JPA2, JSF2, EJB3, etc.).

On peut prendre un MCD témoin ultra simple:

Forum n --- 1 Topic
Topic n --- 1 Message
Message 1 --- n Utilisateur


Architecture 1:
Couche persistance EJB avec entités JPA et leurs DAO (facade remote).
La couche présentation accède aux session bean et utilise les entités JPA comme modèles de données.

Architecture 2:
Couche persistance EJB avec entités JPA et leurs DAO (facade local)
Couche service EJB dont laquelle on y injecte les DAO. Cette couche est quasiment comme un proxy car on utilise les mêmes entités JPA. Cela permettrait d'ajouter quelques traitements métier et DTO si besoin est.
Exemple: je veux afficher la liste des forums et leur nombre total de messages correspondant.
Au lieu d'envoyer la totalité des entités et relations avec les forums; on crée un DTO ForumTO contenant l'id d'un forum, son nom et le nombre de messages. Ce DTO serait généré par la couche de service en s'appuyant sur les DAO.
La couche présentation utilise donc à la fois des entités JPA et des POJO.

Architecture 3:
Couche persistance EJB avec entités JPA et leurs DAO (facade local)
Couche service (façade remote) avec DTO où chaque entité JPA à son ou ses DTO associés.
Le client n'accède plus du tout aux DAO mais à la couche service. Il ne récupère donc plus du tout d'entités JPA mais uniquement des POJO.

Qu'auriez vous pris comme architecture dans le cas d'un développement de web services:
- ajout d'annotations JAX aux entités JPA afin d'avoir pour un même objet Java la possibilité de le manager par JPA et le "marshmaller" par JAX.
- ajout d'annotations JAX aux DTO (dans le cas de l'architecture 3).
- création d'une nouvelle couche utilisant des modèle de données JAX.

Qu'auriez vous pris comme architecture dans le cas des problématiques suivantes:
- client Swing accèdant au serveur via RMI
- client JSF fonctionnant grâce aux injections
- client PHP fonctionnant grâce aux webservices

Si je n'ai pas été très clair veuillez m'en excuser. J'ai un projet personnel assez fatiguant en J2EE sur lequel je travaille, d'où ces questions existentielles! :)

Bon week end à tous

salut, bon sans rentrer dans le details moi ce que j'ai appris ou testé en général :

ne pas exposer les dao : trop bas niveau, tu auras des problemes de performances car trop d'appels. il faut exposer une couche service.

ne pas faire de DTO sauf si c'est un vrai DTO (une aggregation de plein d'objets model differents: dans ce cas ca a un sens)

preferer jax-rs a jax-ws si possible : plus simple, plus performant, plus facile a debugger

ne pas faire de DAO : en fait, ca ne sert a rien : ton PersistanceManager est un superbe DAO generique : autant en profiter et ne pas multiplier les classes de code peu utile.

coté front : swing is dead, rmi ne passe pas les firewall.
moi je ferais du html/js classique avec un framework simple type mvc de base.

Bonjour
lunatix ta vision des choses va à l'encontre de certains patterns (pré)historiques établis tenant lieu de vaches sacrées, mais je suis bien d'accord avec toi le sens de l'ingénierie logiciel est d'aller vers la robustesse et la stabilité donc vers le compactage de la conception et du code.

il parait qu'un programmeur professionnel fait en moyenne 6 bugs pour 1000 lignes de code

J'apporte ma brique à ce post.
En disant les DAOs oui non exposé (localBean) et pour chaque entity
les DTOs à quoi bon ? Les entities sont très bien.
Attention à bien cloisonner les transactions dans la couche service.

Les DAOs sont important malgré un entityManager générique.
Ils exposent les entities aux couches métiers.
De plus un entityManager se connecte à une unité de persistance, quid si tu as des entities manipulés par une couche métier mais plusieurs bases, tu va donc injecter plusieurs entityManager dans ta couche métier, cela va alourdir le code.
Et surtout un DAO n'oblige pas à accéder à des objets en base, peut être ces entities sont elles sur un autre système de stockage via HTTP/LDAP/FileSystem ou autre. c'est l'abstraction pour accéder à ces objets.
Pour finir ce sont les DAOs qui font les requêtes JPQL/SQL/NAMED/NATIVE, pas de requête dans le métier. Donc un DAO par entity.

Dans mes applications métier, j'essaye de mettre minimum 3 couches.

- les DAOs l'abstraction aux objets, où qu'ils soit. ils sont LocalBean et ne peuvent se voir injecter que d'autre DAOs. Et éventuellement certain services de check mais si on peut éviter c'est mieux.

- les services métier en LocalBean, peuvent se voir injecter des DAOs et d'autres services métier.

- Les services boundaries en Remote, il ne peuvent se voir injecter que des services, pas de DAOs et pas d'autres boundaries.

Voilà cela décrit uniquement le métier.
Après en fonction de la techno de l'IHM (s'il y en a une) je crée une autre couche, pouvant être distante aux services métiers. qui construit l'ihm ou fournies les données à l'ihm. cette couche accède aux boundaries via leur interface remote et qu'à eux.

Mon point de vue rejoint un peu hhfr, je ne suis pas aussi réfractaire au DTO, bien au contraire.
Je ne comprends pas cette allergie très répandue contre eux, je leur trouve de nombreux avantages, surtout lorsqu'on utilise des bases de données de conception ancienne. En effet, le type de donnée est souvent obsolète, je prendrais comme exemple les dates en numérique(8) ou des champs char(n) plutôt que varchar, etc...
La couche service, qui dans mon cas sera une facade attaquée en remote, référence les ejb stateless faisant office de DAO, lesquels manipulent les entités via l'entityManager.
Bref, que du standard.
Cette couche service met en forme les données et les transmet via DTO à la couche utilisatrice.
Autre avantage du DTO, il n'expose QUE les données dont à besoin la couche utilisatrice.
De même, plus de problème de lazy loading, les DTO contiennent toutes les données dont a besoin l'utilisateur.
Un autre avantage réside dans l'isolation de l'application par rapport au modèle physique de données, on peut changer la base sans rompre le service sur les anciennes applications.

Citation:

---

Envoyé par lunatix

ne pas faire de DAO : en fait, ca ne sert a rien : ton PersistanceManager est un superbe DAO generique : autant en profiter et ne pas multiplier les classes de code peu utile.
base.

---

:ccool:, j'arrête pas de chanter cette idée dans les projets que je rencontre, c'est vraiment du code quasi inutile, si ce n'est pour plus de lisibilité de code, dans le but où on rattache une fonctionnalité métier à un Service==>EAO/DAO==>Entity. C'était juste une parenthèse, mais je suis ravi de voir que d'autres pensent comme moi.

Personnellement la couche DAO m'est indispensable.
Elle permet certes de faire des accès basiques à la BD que l'EntityManager peut très bien faire mais je l'utilise aussi pour créer des requêtes JPQL bien spécifiques par procédure (moteur de recherche par exemple) ou bien utiliser le pattern Criteria.

Ensuite les DTO peuvent, comme l'a souligné lunatix, être utiles lorsque que l'on utilise des données agrégées. Après c'est vrai qu'utiliser les entités dans les autres couches augmente le couplage client serveur mais je pense que le jeu n'en vaut pas la chandelle lorsque l'on doit coder pour chaque entité une procédure de mapping Entity/DTO.

Au sujet des webservices, étant un novice dans ce domaine, je ne sais pas si on ne perdrait pas en performance lors de la sérialisation des entités JPA au lieu de passer par des DTO plus light et plus orientées client.