19.1. Les DO
Ce sont de simples classes java qui représentent les
entités métier de l'application avec des accesseurs set () et get
(). Les DO sont des objets de type open source ou POJO qui contiennent
l'état de persistance et la fonction métier.
19.2. Les DAO
C'est l'ensemble de classes permettant de cacher le code
manuel SQL/JDBC de la logique métier. C'est le moyen de l'isolation de
la couche persistance de la couche métier. Lors de leur
génération ces classes dispose déjà de
méthodes d'accès aux entités de la base de données
comme la création, modification et suppression de lignes dans les
tables. Or dans le cas d'une requête particulière (un select
conditionné par exemple), on leurs ajoutent de nouvelles méthodes
en utilisant le langage HQL.
19.3. HQL : Langage de
requête d'Hibernate
Hibernate fourni un langage d'interrogation extrêmement
puissant qui ressemble (et c'est voulu) au SQL. Mais ne soyez pas distraits par
la syntaxe ; HQL est totalement orienté objet, comprenant des notions
d'héritage, de polymorphisme et d'association.
19.4. Les Beans
Les objets métiers sont représentés
d'abord par les objets de type « Beans » de l'application
qui établissent le niveau 1 de la couche. On les appelle des
« Beans » parce que leur construction suit les
règles des JavaBeans (Objets sérialisables avec accesseurs) afin
d'être accessible aux bibliothèques de balises Struts qui
travaillent essentiellement avec des Beans Pour ce module, j'ai
implémenté une classe nommée
« PersonneBean.java » qui contient que des méthodes
get et set afin de permettre l'accès aux différents champs de la
classe.
19.5. Les services
Le deuxième niveau de la couche métier se
complète avec la classe « MissionServiceImpl.java»
permettant de réaliser des actions sur les « Beans».
Toutes les règles métier sont à
implémentées dans cette classe qui est accessible via son
interface « MissionService.java». Cette classe joue aussi le
rôle de l'intermédiaire entre la couche présentation et
accès aux données.
19.6. Les interfaces
Dans la communication RPC, nous utilisons beaucoup des
interfaces. Du coté client nous avons le Stub, qui est
représenté par une interface, du coté serveur nous avons
le skeloton qui est représenté par la classe qui
implémente cette interface.
Lorsque la communication est établie, une instance de
chaque objet est créée de chaque niveau de la communication.
Nous avons aussi des interfaces de chaque objet qui
implémente AsynchrCallback
| 
