ePims

Cette section décrit l’organisation des packages ainsi que les points d’interaction entre les objets des différents frameworks. eP-Core ne concernant pas tout ce qui se rapporte à la partie présentation, seuls les objets de persistance de données et ceux propre à la logique applicative sont définis.

Figure: Diagramme de classe globale

• Les objets du package BO (BusinessObject) représentent les données du model (en l’occurrence celles de la base de données). Ces objets ne contiennent que des informations (des attributs) mais pas de ‘comportements’. Ils sont accessibles dans toutes les couches de l’application.
• Le package DAO contient les classes qui ont la charge de la persistance des données (utilisation du framework Hibernate). Seules les interfaces doivent être accédées afin de permettre tout changement d’implémentation de manière transparente. En effet, le framework Spring permet de spécifier (aux classes services) la classe d’implémentation via le mécanisme d’inversion de contrôle (IoC) par injection par accesseur : utilisation d’un fichier de configuration et accès aux setter méthodes. Spring prend également en charge la gestion des sessions/transactions pour Hibernate : les classes DAO doivent étendre la classe HibernateDaoSupport qui prend en charge les accès JDBC.
• Le package Service contient les interfaces qui doivent être utilisées par toutes les autres applications (ou couches) afin de manipuler (créer, modifier, supprimer) les objets de données. Les classes d’implémentation des services doivent définir des setter méthodes pour les classes DAO afin d’être configurées par Spring (voir paragraphe précédent).

En résumé, la couche model rend visible d’une part les objets représentant les données (package BO) et, d’autre part, les interfaces Services qui permettent de manipuler ces données.

On retrouve donc dans les fichiers de configuration xml : (spring-*.xml)

• La définition de la dataSource utilisée par Hibernate pour accéder à la DB.
• La définition des différentes propriétés propres à Hibernate (mapping files…)
• La définition des dao : description des beans et spécification de la propriété hibernateTemplate.
• La définition des services : description du bean et spécification des propriétés qui seront positionnées via les accesseurs.

REMARQUE : ServiceLocator recherche dans l’ApplicationContext qui lui est spécifié les beans correspondants à l’implémentation de IXXXService (définit dans spring-*.xml).

L'objectif est d'obtenir la même architecture que celle décrite ci-dessus mais en utilisant les outils de génération automatique et en évitant au maximum de devoir définir des “template” maison.

Le fichier ./hibernate.reveng.xml est le fichier de Reverse Engineering de Hibernate. Il permet de spécifier, entre autre, des noms de classes différentes que ceux proposés par défaut pour certaines tables.

  o table ms_protocol  => classe cea.edyp.epims.domain.dao.impl.MSProtocol
  o table msms_protocol => classe cea.edyp.epims.domain.dao.impl.MSMSProtocol
  o table gel_1d => classe cea.edyp.epims.domain.dao.impl.Gel1D
  o table gel_2d => classe cea.edyp.epims.domain.dao.impl.Gel2D
  o table gel_1d_migration  => classe cea.edyp.epims.domain.dao.impl.Gel1DMigration
  o table gel_2d_migration  => classe cea.edyp.epims.domain.dao.impl.Gel2DMigration
  o table sample_species => classe cea.edyp.epims.domain.dao.impl.Species
  o table sample_subcellular_localisation => classe cea.edyp.epims.domain.dao.impl.SubCellularLocalisation

Cette partie est en cours de mise en place et est donc susceptible d'évoluer en permanence !

Actuellement pour la génération automatique nous utilisons Hibernate Tools comme plugin Eclipse. Les règles / spécificités que l'on souhaite conserver :

• Absolument
  • séparation des POJOs et DAOs dans des packages différents : OK Avec Hibernate Tools !
  • séparation interface / implémentation pour les DAOs : OK Avec Hibernate Tools !
• Éventuellement
  • deux niveaux de hiérarchie pour les POJOs : Semble problématique ! A Voir !!

De plus les modifications entrainées par le changement de générateur doivent impacter au minimum les modules utilisant eP-Core.

Pour les différentes générations automatiques décrites ici, il est nécessaire de définir une configuration hibernate.

Dans la perspective Hibernate et la vue Hibernate Configurations, cliquer droit et choisir “add Configuration”. Choisir un nom, <ePCore_config>, et saisir les informations suivantes:

• Dans l'onglet Main :
  • type : Core
  • Project : eP-Core
  • Configuration file : \eP-Core\resources\hibernate\hibernate.cfg.xml
• Dans l'onglet Mappings :
  • Entrer tous les fichiers hbm.xml qui sont définis dans /eP-Core/src/mapping/cea/edyp/epims/domain/mapping

De la même manière, il faut définir un Hibernate Code Generation (<HCG>) ou launch configuration. Un même HCG peut être utiliser pour générer en une seule fois tous les objets et documents. Mais ceci peut poser un problème puisque tous les objets ne doivent pas être générés à chaque fois !! A chacun de gérer sa/ses HCG et à être attentif aux objets générés lors de l'exécution de celui-ci ! Nous décrirons dans la doc trois configurations différentes selon que l'on souhaite générer la documentation du modèle, les objets du domaines ou les DAO.

Les tables suivantes ne nécessitent pas de classes DAOs:

1. prog_contact
2. proj_contact
3. study_contact
4. samples_share

Les DAO sont générés dans le répertoire source “src/main” et

• le package “cea.edyp.epims.domain.dao.impl” pour les classes d'implémentation. Une méthode static permet d'obtenir une instance de la classe à partir d'un context spring. Cette méthode suppose que le bean correspondant à cette classe est identifié par un nom = nom de la classe !
• le package “cea.edyp.epims.domain.dao” pour les interfaces. Seules les interfaces sont référencées dans les services.

Pour cela, depuis Eclipse, ouvrir la perspective Hibernate et accéder à la boite de dialogue Hibernate Code Generation, (en passant par le menu Run > Hibernate Code Generation > Open Hibernate Code Generation Dialog).

Créer un Hibernate Code Generation (<HCG>) ou launch configuration en spécifiant

• Dans l'onglet Main
  • un nom,
  • Console configuration : le nom de la configuration hibernate créé (voir ci-dessus), <ePCore_config>.
  • Output directory : \eP-Core\src\main
• Dans l'onglet Exporters
  • Sélectionner l'option “Use Java 5 Syntax” (afin d'utiliser les Generic)
  • Selon que l'on souhaite générer les interfaces et/ou les classes pour les DAO, il faut sélectionner un ou deux Generic Exporter configuré(s) comme ceux indiqués ci-dessous. On peut ajouter et configurer autant de Generic Exporter que voulu en sélectionnant add dans l'onglet Exporters.
    • Les paramètres pour les templates et le pattern pour la localisation et le nom de fichier diffèrent.
    • Remarque : Il est possible d'exécuter le(s) exporter(s) que sur un sous-ensemble de fichiers mapping (les nouveaux par exemple). ceci afin de ne pas écraser les interfaces existantes… Pour cela il faut utiliser une console configuration dans laquelle seuls ces fichiers auront été spécifiés.

Figure: Génération automatique des DAO Hibernate

Attention: Certaines interfaces sont enrichies. La génération automatique ne doit donc pas être faite systématiquement et doit être faite avec précaution !

Après génération des classes DAO, certaines modifications manuelles sont nécessaires. En effet, ces classes sont générées en fonction de templates correspondant à la définition des interfaces. Si des modifications manuelles sont faites au niveau des interfaces, il est nécessaire de les répercuter au niveau des classes.
Par exemple (seul exemple pour le moment ! ), pour l'objet Study :

• Les objets du domaines cea.edyp.epims.domain.AbstractStudy et cea.edyp.epims.domain.Study sont généres (cf ci-dessous)
• La classe cea.edyp.epims.domain.dao.impl.StudyDAO et l'interface cea.edyp.epims.domain.dao.IStudyDAO ont été générées.
• La méthode refreshLazy() a été ajoutée à l'interface IStudyDAO. Nous avons défini une classe EPCoreStudyDAO dérivée de StudyDAO qui implémente cette méthode. Par contre, la classe StudyDAO n'implémente pas toutes les méthodes de IStudy, par conséquent une erreur est levée. Pour remédier à cela, la classe StudyDAO est déclarée abstraite.

Figure: Diagramme de classes exemple pour les DAO Hibernate

Les Objets du domaines sont générés depuis les fichiers *.hbm.xml, dans le répertoire source src/main.

Attention:
La génération automatique n'est actuellement pas en place. Hibernate Tools ne permettant pas de générer pour chaque classe du domaine, une classe abstraite. Deux solutions :

• Revoir la hiérarchie des classes du domaines pour adopter celle générée par Hibernate Tools : Le problème réside dans la conservation des modifications manuelles : Voir avec les possibilités du tag <meta> class-code…
• Créer un ReverseEngineeringStrategy propriétaire pour générer ces 2 niveaux.

Le Custom code actuellement définis :

• A voir : les méthodes equals / hashcode / toString : cf meta tag use-in-equals et use-in-tostring
• Acquisition : Définition des Natures autorisées.
• AcquisitionResult : Méthode Boolean getArchived()
• Actor : Définition des Roles autorisées. devrait être dans ActorRole ?!
• AttachedFile : Définition des Types autorisées.
• Program : Méthodes isClosed et CloseProgram
• Project : Méthodes isClosed et CloseProject
• Sample : Définition des Status autorisées.
• Study : Définition des Status autorisées + Méthodes isClosed et CloseStudy et setSamples
• VirtualPlate : Méthodes addWell et isFull

Pour chaque classe du domaine, une classe abstraite est créée. Seules les classes mères abstraites “AbstractXXX” sont systématiquement générées. A verifier avec Eclipse : Les sous classes ne sont générées que la première fois ce qui permet de les personnaliser sans tout perdre à chaque génération.

Figure: Diagramme de classes exemple pour les objets du domaine

Seules les interfaces IxxxService sont visibles depuis toute autre application (telle que la couche présentation) qui utilisera eP-Core. Ces interfaces devront fournir les méthodes nécessaires pour l’accès aux données en lecture et en écriture.

Les méthodes pour l'écriture des données sont de la forme :

• public Sample saveSample(Sample sample)throws EPimsServiceException; Sauvegarde d'un élément (ici Sample) déjà existant. L'objet sauvegardé est retourné.
• public Sample createSample(Sample sample) throws EPimsServiceException; Création d'un nouvel élément. L'objet créé est retourné.
• public void deleteSample(Sample sample) throws EPimsServiceException; Suppression d'un élément

Pour les accès en lecture, les services sont écrits selon le principe suivant :

• on définit un objet enum contenant un ensemble de requêtes retournant des objets (du type de l'entité que représente le service) en appliquant des filtres specifics.
• on définit une méthode générique (getSamples(enum.query, args)) permettant d'exécuter ces requêtes. Cette méthode reçoit une des requêtes prédéfinies en paramètre ainsi que le/les argument(s) dont peut avoir besoin cette requête, et retourne une liste des valeurs resultantes.

Il est certain que certaines actions ne peuvent être appliquées par une simple requête (aussi compliquée qu'elle puisse être !!), à ce moment là, les services peuvent aussi avoir des méthodes exécutant des tâches partiulières.

les classes d'implémantation des services utilisent donc des objets typés par les interfaces des DAOs. Spring gère le lien entre ces objets :

* Dans le fichier SpringAppContext.xml :

     <bean id="contactServiceTarget" class="cea.edyp.epims.service.impl.HibernateContactService"> 
         <property name="actorDao"><ref bean="ActorDAO"></ref></property>
         <property name="contactDao"><ref bean="ContactDAO"></ref></property>
         <property name="actorRoleDao"><ref bean="ActorRoleDAO"></ref></property>
         <property name="companyDao"><ref bean="CompanyDAO"></ref></property>
      </bean>
        <!-- Transactional proxy Services -->   
      <bean id="baseTransactionProwy" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"  abstract="true">
         <property name="transactionManager"><ref local="transactionManager"/></property>
         <property name="transactionAttributes">
             <props>
                 <prop key="get*">PROPAGATION_REQUIRED,readOnly</prop>
                 <prop key="save*">PROPAGATION_REQUIRED</prop>
                 <prop key="create*">PROPAGATION_REQUIRED</prop>
                 <prop key="delete*">PROPAGATION_REQUIRED</prop>
             </props>
         </property>
     </bean>
     ...
     <bean id="contactService" parent="baseTransactionProxy">
        <property name="target"><ref local="contactServiceTarget"/></property>
    </bean>

• Et pour les DAOs :

    <bean id="ActorDAO" class="cea.edyp.epims.domain.dao.impl.HibernateActorDAO"  >
        <property name="hibernateTemplate"><ref bean="hibernateTemplate"/></property>
    </bean>

(Continuez vers la suite de la documentation ⇒ epcorespring)