Application n tiers - conseil de conception et outils

Bonsoir,



je suis en plein développement d'une application Java avec 2 grosses parties :

1. IHM
2. Métier
3. Persistance

Cependant, je ne sais pas quels outils prendre. Pour l'IHM, je pense là faire sur Swing donc implémenter le pattern MVC.


Pour le métier, je ne sais pas quoi faire. Utiliser du RMI Simple, EJB 3, Web Service ?.... De plus quels pattern utiliser ici ? (Cependant, l'implémentation de DTO est obligatoire pour envoyer des objets entre l'IHM et la couche Métier). La création d'un web service me semble bien. Ainsi, je pourrais faire appels a celui-ci quelque soit le langage et type de terminal (ordinateur, terminal dans une gare par exemple..., téléphone) sauf erreur de ma part.

Persistance, je doit pouvoir sauvegarder les données aussi bien dans des fichiers texte, xml, envoyer les données sur un autre serveur, une base de données. Après quelque recherche je pense utiliser DAO ici. Avec pour les DAO de base de données Hibernate. (Le choix vous semble t'il correct ?)

Pour chaque couche, nous avons bien sur des interfaces qui sont manipuler par la couche supérieur. Ainsi la couche IHM connais les interface métier de la couche métier mais ne connais pas l'implémentation.
Donc, je peux utiliser Spring et modifier facilement les références de mes objets.

Pouvez-vous me donner vos avis et choix de conception ? De plus, j'ai entendu parler de SOA. Ce pattern peut-il m'aider pour le développement de mon application ?

merci.

Bonjour,

Le principal point de ton architecture, et je crois que tu l'a bien compris, c'est que tes couches soit indépendantes.

Pour la partie IHM, je ne connais pas trop swing, mais le choix ne me parait pas idiot.

Pour la partie métier, je ne te conseille pas de partir sur des technos trop compliquées ou mal maitrisées. Si ta couche métier est bien écrite, générer des webservices à partir de cette couche n'est pas très difficile et rapide (quand on connait).

Pour la partie persistance, j'aime bien hibernate pour l'accès aux données, mais les ejb3s sont tout aussi appropriés.

Le tout avec spring pour faire de l'injection de dépendance, c'est bien. Ça permet de bien maintenir tes couches indépendantes.

Par contre, j'ai pas trop compris pourquoi tu ne veux pas tout simplement appeler tes couches directement (au moins dans un premier temps).
Pour moi, voila comment j'aurais architecturé ton projet :

* une classe dao qui accède à ta base de donnée
* une classe métier qui appelle ta classe dao en faisant de l'injection de dépendance.
* une classe IHM qui appelle ta classe métier en faisant de l'injection de dépendance.
Le tout avec des interfaces.

Puis dans un deuxième temps, j'aurai rendu accessible ma partie métier en présentant des webservices à l'aide de technos comme xfire, ou spring webservices.

En tout cas, les conseils que je peux te donner sont :
- que ton architecture tienne la route. Une mauvaise architecture peut te donner du fil a retordre par la suite.
- ne partir sur des techno qu'après les avoir testées. Les ejb3, ou hibernate ne sont pas facile à mettre en oeuvre.
- bien comprendre ce qui se passe lorsque tu utilises des framework comme spring. Et aussi quels sont les aboutissants de telles techno.



Voila j'espère que ça peux t'aider.

Le choix est vraiment très vaste, ça varie beaucoup selon le besoin et les compétences.
par exemple on s'oriente vers les web service si l'application est hétérogène.
SOA pour une application distribué. Pour les interfaces ça dépend des compétence en web design.