This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
wiki:epims4_1m1:developer:epcorearchitecture [2009/04/21 17:44] 127.0.0.1 édition externe |
wiki:epims4_1m1:developer:epcorearchitecture [2010/07/16 11:42] (current) 132.168.73.247 |
||
---|---|---|---|
Line 23: | Line 23: | ||
**REMARQUE** : ServiceLocator recherche dans l’ApplicationContext qui lui est spécifié les beans correspondants à l’implémentation de IXXXService (définit dans spring-*.xml). | **REMARQUE** : ServiceLocator recherche dans l’ApplicationContext qui lui est spécifié les beans correspondants à l’implémentation de IXXXService (définit dans spring-*.xml). | ||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
==== La pratique ==== | ==== La pratique ==== | ||
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. | 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. | ||
Line 93: | Line 75: | ||
\\ | \\ | ||
2.\\ | 2.\\ | ||
- | De la même manière, il faut définir un ''Hibernate Code Generation'' (<HCG>) ou ''launch configuration'' (Bouton "Run", Option "Open Hibernate Configuration Dialog"). Un même HCG peut être utiliser pour générer en une seule fois tous les types d'objets et documents (POJOs, DAO, modèle). 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 ! | + | De la même manière, il faut définir un ''Hibernate Code Generation'' (<HCG>) ou ''launch configuration'' (Bouton "Run Hibernate", Option "Open Hibernate Configuration Dialog"). Un même HCG peut être utiliser pour générer en une seule fois tous les types d'objets et documents (POJOs, DAO, modèle). 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 : | Nous décrirons dans la doc trois configurations différentes selon que l'on souhaite générer : | ||
* les DAO (voir chapitre ci-dessous) | * les DAO (voir chapitre ci-dessous) | ||
Line 252: | Line 234: | ||
== Règles de développement == | == Règles de développement == | ||
- | Les méthodes pour l'écriture des données sont de la forme : | + | 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 saveSample(Sample sample)throws EPimsServiceException; Sauvegarde d'un élément (ici Sample) déjà existant. L'objet sauvegardé est retourné. | ||
Line 258: | Line 240: | ||
* public void deleteSample(Sample sample) throws EPimsServiceException; Suppression d'un élément | * 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 : | + | 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. | + | L'accès en écriture est pour l'essentiel géré par des requêtes. Ces requêtes retournent des objets du domaines suivant des filtres / caractéristiques bien définis. Par conséquent, on appellera la requête X qui retourne les études "blabla" par la méthode List getStudy(X) |
+ | Dans l'interface Service (XXXService), on définit un ensemble d'enum. Chacun des enum étant des requêtes qui retourne un même type de donnée. Ainsi, on aura: | ||
+ | * Les méthodes : List getObjA(ObjAQueries), List getObjB(ObjBQueries) et mêmes méthodes avec des paramètres pour les paramètres des queries. | ||
+ | * enum ObjAQueries qui définit un ensemble de requetes pouvant être passé en paramètre à getObjA et retournant des objets de type ObjA | ||
+ | * enum ObjBQueries qui définit un ensemble de requêtes pouvant être passé en paramètre à getObjB et retournant des objets de type ObjB | ||
+ | |||
+ | Pour les données annexes de type autre que des objets du domaine (nombre d'acquisitions, liste des modèle de spectro disponible, ...) on définit : | ||
+ | * une méthode List getAssociatedXXXObjects(AssociatedXXXQueries) | ||
+ | * enum AssociatedXXXQueries qui définit un ensemble de requêtes pouvant être passé en paramètre à getAssociatedXXXObjects | ||
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. | 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. |