Discussion :

[mlequim]

hello,

nous créons un site web avec struts en présentation et spring pour séparer les couches. Nous faisons de l'injection de dépendance pour injecter dans la couche business des DAO et pour injecter des services dans la présentation. Cependant les DAO n'auront probablement dans le futur qu'une seule implémentation, ainsi que les services. Quel avantage y à t'il alors à utiliser spring ? nous avons pensé à :

- les tests unitaires
- remoting avec spring ? à moins que l'injection de dépendance ne soit pas obligatoire pour cela ?
- les interfaces documentent le code

cela ne semble pas beaucoup,...

y à t'il d'autres avantages ?

[zekey]

- Le mécanisme de transactions sur la couche métier.
- La programmation orientée Aspect.

[dlemoing]

Premiere régle du GoF (Gang of Four, groupe à l'origine du livre de référence sur les Design Patterns) : Program to an interface, not an implementation.

Les avantages de spring :
- utiliser des interfaces constitue une bonne pratique qui est facilitée par l'utilisation de Spring (cf le GoF)
- les tests unitaires pour tester en isolation chacune des couches (cela revient à injecter une implémentation bidon de DAO par exemple)
- l'utilisation d'un framework d'AOP : gestion déclarative d'un certain nombres de services qui utilisent les proxy dynamiques de java (interfaces obligatoires)
- gestion déclarative des transactions
- gestion de la sécurité (avec Acegi)
- gestion des exceptions (transformation des erreurs techniques en unchecked exceptions, ...)
- spring remoting : oui si tu veux mais ce n'est pas indispensable
- intégration avec d'autres frameworks (Hibernate, iBatis, JDO, Toplink, Struts, Velocity, JSF, Webflow, Acegi, Quartz, EJB, JMS, etc...)
- framework présentant une cohérence et une uniformité
- pas (ou peu) de dépendances avec l'API de Spring

[mlequim]

- Le mécanisme de transactions sur la couche métier.
- La programmation orientée Aspect.

merci pour ta réponse

la programmation orientée aspect n'est pas encore un standard et a beaucoup de détracteurs, je préferre attendre avant de l'utiliser.

Pour le mécanisme de transactions je ne m'y connais pas, peux tu expliquer un peu plus ou me donner un lien à lire ?

[mlequim]

Premiere régle du GoF (Gang of Four, groupe à l'origine du livre de référence sur les Design Patterns) : Program to an interface, not an implementation.

Les avantages de spring :
- utiliser des interfaces constitue une bonne pratique qui est facilitée par l'utilisation de Spring (cf le GoF)
- les tests unitaires pour tester en isolation chacune des couches (cela revient à injecter une implémentation bidon de DAO par exemple)
- l'utilisation d'un framework d'AOP : gestion déclarative d'un certain nombres de services qui utilisent les proxy dynamiques de java (interfaces obligatoires)
- gestion déclarative des transactions
- gestion de la sécurité (avec Acegi)
- gestion des exceptions (transformation des erreurs techniques en unchecked exceptions, ...)
- spring remoting : oui si tu veux mais ce n'est pas indispensable
- intégration avec d'autres frameworks (Hibernate, iBatis, JDO, Toplink, Struts, Velocity, JSF, Webflow, Acegi, Quartz, EJB, JMS, etc...)
- framework présentant une cohérence et une uniformité
- pas (ou peu) de dépendances avec l'API de Spring

marchi ,

- quand tu dis que spring remoting n'est pas indispensable, tu veux dire qu'il n'est pas indispensable de l'utiliser ou qu'il n'est pas indispensable d'utiliser le core de spring avec spring remote ?

[dlemoing]

la programmation orientée aspect n'est pas encore un standard et a beaucoup de détracteurs, je préferre attendre avant de l'utiliser.

C'est bien dommage, l'AOP est depuis 5 ans la principale avancée en terme de développement. Il n'y a bien sur pas de normes sur le sujet mais il existe des frameworks plus ou moins puissants et légers : AspectJ, Spring AOP ou JBossAOP.

Pour le mécanisme de transactions je ne m'y connais pas, peux tu expliquer un peu plus ou me donner un lien à lire ?

La documentation sur le site de Spring ou les articles techniques dispos. Au passage, je signale que Spring utilise l'AOP pour la gestion déclarative des transactions.

quand tu dis que spring remoting n'est pas indispensable, tu veux dire qu'il n'est pas indispensable de l'utiliser ou qu'il n'est pas indispensable d'utiliser le core de spring avec spring remote ?

Je dis ca parcequ'il n'est pas forcement nécessaire de rendre distribuée son appli. Si tu veux le faire en utilisant des Web Services, il faut que tu t'appuies sur Axis et pas Spring. Si tu veux faire du RMI ou autre choses, Spring peut t'aider à distribuer des composants simplement.

[mlequim]

merci pour ces clarifications ,

par contre pour l'AOP, arrête moi si je me trompe car je ne suis pas un spécialiste, l'AOP ne respecte pas l'encapsulation en POO non ? cela ne risque pas de faire des programmes spaguettis ? un peu comme ce qu'était le goto pour la programmation procédurale ?

[dlemoing]

Prenons un exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public interface InterfaceMetier {
    public void doSomething() throws ApplicationException;
    public void doToto() throws ApplicationException;
}

Un des besoins est d'envoyer un mail en cas de levée d'une ApplicationException. En POO, on ferait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public class Implementation implements InterfaceMetier {
    ...
    public void doSomething() throws ApplicationException {
        try {
            something();
        }catch (ApplicationException e) {
            envoyeurDeMail.send(e);
            throw e;
        }
    }
 
    public void doToto() throws ApplicationException {
        try {
            toto();
        }catch (ApplicationException e) {
            envoyeurDeMail.send(e);
            throw e;
        }
    }
 
}

Si je rajoute une nouvelle méthode métier dans cette interface avec la meme contrainte, je dois reprendre la gestion sous forme de try/catch. Cela entraine de la duplication de code, des risques d'erreurs ou d'oubli...

Avec l'AOP tu vas déclarer que la levée d'une exception va entrainer l'envoi d'un mail et ton code devient :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
public class Implementation implements InterfaceMetier {
    ...
    public void doSomething() throws ApplicationException {
            something();
    }
    public void doToto() throws ApplicationException {
            toto();
    }
}

C'est plus clair non ? Ou est le code spaghetti ? Pour l'implémentation de l'aspect tu as plusieurs choix (AspectJ, Spring, JBoss). Avec Spring, ca pourrait donner :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class EmailNotificationThrowsAdvice implements ThrowsAdvice {
    private MailSender mailSender;
 
    public void setMailSender(MailSender mailSender) {
        this.mailSender = mailSender;
    }
 
    public void afterThrowing(Exception ex) throws Throwable {
        if (ex....)
            mailSender.send(...);
        else
            //autre traitement si on ne repond pas à certaines conditions (type d'exception, stacktrace, ...)
    }
}

l'AOP ne respecte pas l'encapsulation en POO non ?

Qu'est ce qui te fait penser ca ?

[mlequim]

en effet c'est plus clair,

par contre on externalise le code de gestion des exceptions d'une classe hors de la classe donc on ne respecte pas l'encapsulation non ? mais vu l'exemple que tu as donné c'est un moindre mal car le code en deviens plus clair,...

je vois déjà un peu mieux l'avantage de l'AOP, je pense que mes remarques étaient du à ma méconnaissance de l'AOP, je vais donc l'étudier pour en avoir un avis plus objectif.

merci pour ton exemple

[dlemoing]

par contre on externalise le code de gestion des exceptions d'une classe hors de la classe donc on ne respecte pas l'encapsulation non ? mais vu l'exemple que tu as donné c'est un moindre mal car le code en deviens plus clair,...

Je n'exclue pas de gérer les exceptions dans mes classes plutot que dans des aspects, mais je le ferais uniquement pour répondre à une problèmatique métier.

Par exemple, si mon CompeDAO envoie une exception s'il ne trouve pas de compte associé à un numéro passé en parametre :
- mon aspect transactionnel va certainement faire un rollback de la transaction : aspect technique
- mon code va gérer la CompteNotFoundException et sera quoi faire dans ce cas (rediriger l'utilisateur pour le création d'un compte ou lui laisser la possibilité de ressaisir son numéro) : fonctionnel qui a sa place dans mon code

Les aspects doivent être utilisés surtout pour ce genre de problematiques techniques et d'intégration (transaction, sécurité, audit, ...).

[mlequim]

merci pour la liste des avantages de spring, par hasard vous ne connaissez pas un lien qui me les donnerait tous ou presque tous ?