Surveiller ce forum | 
Commencer une nouvelle discussion
| RE: proto Struts2, Spring, IBatis [ Répondre ] Par : Benjamin Leperchey on 2008-01-16 11:41 | [forum:53105] |
|
oui mais l'idée serait de coupler Spring et "StrutsACube" (renommé si je me souviens bien en "AcubeView") les avantages de cette brique "maison" par rapport à la transformation XSLT de Struts2 : - paramétrage du formatage XML initial, qui permet d'éviter les feuilles de style dans la majorité des cas, - réutilisation du paramétrage pour désérialiser automatiquement le XML produit, pour consommee des "services web" ACube - intégration de FOP pour les éditions simples |
|
| RE: proto Struts2, Spring, IBatis [ Répondre ] Par : Cyril Rocheteau on 2008-01-15 18:56 | [forum:53104] |
|
3 j/h ont été nécessaire pour ce proto, vu que nous utilisons ces trois frameworks. Pour Spring MVC, cela prendrait plus de temps. En effet, Spring MVC est volontairement restreint sur l'aspect XSLT. voir la page http://static.springframework.org/spring/docs/2.5.x/reference/view.html#view-xslt et l'extrait suivant : "There are software packages available that will automatically 'domify' an object graph, but within Spring, you have complete flexibility to create the DOM from your model in any way you choose. This prevents the transformation of XML playing too great a part in the structure of your model data which is a danger when using tools to manage the domification process." |
|
| RE: proto Struts2, Spring, IBatis [ Répondre ] Par : Grégory Picavet on 2008-01-15 18:47 | [forum:53103] |
|
3) le prototype montre que l'injection du service dans l'action peut se faire automatiquement (mode autowired) ou de manière déclarative dans le fichier appContext. Dans le 1er mode (illustré par l'action products/list), Struts2 instancie l'action mais récupère la dépendance auprès de Spring (la seule manière est en autowired). Dans le 2e mode (illustré par les actions edit, add, del), Struts2 demande à spring l'instanciation + l'injection de dépendance. Cette injection est alors décrite dans le fichier appContext.xml (elle aurait pu être omise et dans ce cas, résolue par autowired) Un projet important utilisera sans doute la 2e méthode. 4) La démarcation de transaction peut effectivement se faire en xml, avec l'utilisation d'aop, et selon un pattern à expression régulière (histoire de tout démarquer d'un coup:). Cette solution supprime en plus la dépendance sur les annotations :) Sinon la dépendance sur ActionSupport n'est obligatoire, elle permet simplement à Struts d'injecter des données sur la validation,de pouvoir agir dessus puis de les récupérer dans la phase de rendu. L'inconvénient est qu'on crée une dépendance sur le framework (donc ce plus vraiment un pojo), mais on reste toujours indépendant de l'api servlet (gros intéret pour les tests unitaires) |
|
| RE: proto Struts2, Spring, IBatis [ Répondre ] Par : Benjamin Leperchey on 2008-01-15 17:48 | [forum:53102] |
|
C'est très convaincant... j'aime beaucoup, dans le désordre : 1) les "interceptors" Struts2, qui permettent de factoriser proprement la gestion des exceptions (par configuration plutôt que par une BaseAction), 2) l'utilisation de l'injection de dépendances plutôt que des fichiers de propriétés "maison". C'est évidemment infiniment plus souple, et on garantit une syntaxe cohérente (et standard) pour toutes les configs 3) l'injection des objets "service" dans les actions (d'ailleurs, je n'ai pas trouvé le lien entre struts.xml et appContext.xml ?) En particulier, l'utilisation des façades qui rendent la création des "Delegate" implicite allège le code des actions, ce qui est toujours bon à prendre. 4) les transactions déclaratives, sans "TransactionManager". Ca vaudrait peut-être le coup de creuser du côté AOP Spring pour les sortir complètement du code mais j'ai des doutes : on éviterait des oublis, mais d'un aute côté je trouve ça plus lisible avec des annotations. A mon avis, le gros avantage d'iBatis par rapport à Hibernate ou autre, c'est (paradoxalement) qu'on écrit soi-même le SQL. Au moins, on sait ce qui se passe. La majorité des actions ACube étant "transactionnelles", il est de toute façon naturel d'expliciter les commits. L'injection de dépendance apportent évidemment des bénéfices substantiels. Reste à voir l'effort de migration nécessaire pour les applis existantes, ou la possibilité de faire cohabiter des "vieux" Delegate et DAO avec des nouveaux. Il reste quand même la question d'utiliser le MVC Spring plutôt que Struts2. Je reste convaincu que ça serait aussi simple, et que ça nous éviterait une technologie supplémentaire -- même si, comme ma question sur le point 3 le montre, elles sont assez remarquablement bien intégrées. Une autre question : à quoi sert la dépendance "ActionSupport" ? Est-ce qu'on peut utiliser des POJO, et si oui, qu'est-ce qu'on perd ? |
|
| proto Struts2, Spring, IBatis [ Répondre ] Par : Grégory Picavet on 2008-01-15 16:46 | [forum:53101] |
|
un prototype pour la modernisation de LISE s'appuyant sur Struts2, Spring et Ibatis est disponible dans la zone "feature-request" de LISE (war + pdf) Ce prototype se base sur le prototype "Struts2" publié précédemment (https://admisource.gouv.fr/tracker/index.php?func=detail&aid=527&group_id=8&atid=217), avec quelques modifications sur la partie Struts2 : - paramétrage du controleur dans struts.xml à la place des annotations. - remplacement des url *.action en *.xml et redirection de "/flux/protected/*" vers le controlleur La nouveauté est le couple Spring DAO et iBatis qui permet une réduction significative du code et de la configuration de la couche DAO A noter que Spring & Ibatis peuvent également s'intégrer facilement à Struts 1.1 + StrutsCX pour une utilisation à court terme dans les projets. |
|
