IoC ou Service Locator

Salut à tous,

Je suis (toujours) en stage, et j'ai (encore) besoin d'un petit conseil ...

Je pense que pour avoir une réponse à ma question, il faut d'abord que j'explique pourquoi je dois la poser ...

Je dois réaliser une application Web relativement importante (en taille ... On a une 50aine de tables). Pour éviter de réinventer la roue, j'ai décidé de passer pas mal de temps dans l'étude des divers framework existant ... Du coup, j'ai choisi d'utiliser Hibernate pour la persistance, les Facelets pour la vue et JSF pour orchestrer tout ce bordel. Jusque là pas trop de soucis.

Du coup, j'ai créé des classes à persister, des classes DAO pour accéder aux instances persistantes, des services pour la couche métier (même si je ne saisi pas trop la différence entre DAO et service pour l'instant) et des backing-beans pour effectuer les actions ... Jusque là, rien de folichon.

Le soucis, c'est que je me suis rendu compte que dans les best-practices d'Hibernate, l'idéal pour mon cas est de créer une session par requête, et 2 transactions : une pour l'écriture (création, modification ou mise-à-jour) et une pour la lecture. Et en fait, je suis obligé de faire ça, sinon j'ai pas mal de soucis (modification en base non répercutée sur les objets, etc.).

Du coup, je me suis renseigné, et il se trouve que le framework Spring permet régler soit disant de régler ce point. Ok ...

Mais maintenant que je me suis plongé dedans et je comprends mieux comment ça marche, il y a un point qui reste flou ... Pourquoi utiliser l'injection de dépendances (IoC) qui est quand même relativement lourde à mettre en place, alors qu'une simple classe statique ServiceLocator peut faire l'affaire ?

Globalement, dans mes backing-beans, c'est là que les services sont utilisés.  Du coup, si je fais de l'IoC, je dois modifier chaque classe et chaque configuration si pour telle ou telle raison je dois créer un nouveau service ... Et ça c'est plutôt lourd. A l'inverse, si je fais un registre ServiceLocator, il n'y a que cette classe que je dois changer ...

Donc voilà ma question ... Quel choix dois-je faire dans mon cas : sortir l'artillerie lourde avec l'IoC, seulement parce que tout le monde en parle sur le Net en disant que c'est l'avenir ?

Merci beaucoup pour votre aide ... Je pense qu'un vrai débat qui pourrait servir à d'autre débutant pourrait être très interessant !

LocalStone

Salut,
il est vrai que Spring est coûteux à mettre en place, de même qu'hibernate est couteux à mettre en place (par rapport à du JDBC traditionnel).
En gros si tu appli comporte énormement d'objets à instancier et à gérer il est interressant d'utiliser Spring en travaillant par composition (pour essayer de découpler un max ton code et ne pas trop dépendre de Spring).Un des points interressant de Spring est justement le fait de pouvoir le coupler à hibernate et lui laisser la responsabilité de gérer les transactions (TransactionManager).

 Ensuite si ton apli reste somme toute assez modeste tu pourras te servire d'un BeanFactory et d'un serviceLocator tous deux faits maison.

Bon après tout dépend de ton appli et du fait de vouloir en faire un vitrine techno ou pas .

PS: Différence entre DAO et service : Le DAO vas te rapporter ta donnée brute de décoffrage de la BDD sans ne jamais appliquer de règle métier sur les données. La couches service elle appliquera toute transformation, ou règle de gestion nécessaire avant de retourner ton objet à tes backing-beans.

--- Moucave , petit singe au pays du j2ee  ---