Pourquoi il vaut mieux éviter d'écrire le processus métier (ou une partie du processus métier) dans le backing bean

C'est un principe général mais voyons concrètement les raisons pour ce cas précis.

On aurait pu écrire ceci dans le backing bean (NE LE FAITES PAS !) :

  public String enregistrerMouvement() {
    if (typeMouvement.equals("ajout")) {
      compte.deposer(montant);
    } else {
      compte.retirer(montant);
    }
    gestionnaireCompte.update(compte);
    Util.addFlashInfoMessage("Mouvement enregistré sur compte de " + compte.getNom());
    return "listeComptes?faces-redirect=true";
  }

Quels sont les problèmes ?

• Si on insère le code ou une partie du code d'un processus métier dans un backing bean, les différentes parties du traitement ne sont plus clairement séparées. Le code du processus métier va "polluer" le code du backing bean qui est chargé de la bonne marche de l'interface utilisateur. Quand le code métier est très simple comme ci-dessus, on peut penser que ça n'est pas grave mais les règles de gestion peuvent changer et le code métier peut devenir alors plus complexe. Exemple de changement de règle de gestion qui provoquerait une modification du code : les retraits d'argent plus élevés que le solde sont autorisés mais ils provoquent le calcul de frais bancaires qui devront être payés par le client de la banque. Le code va devenir bien plus complexe, avec, sans doute, une exception lancée par la méthode retirer, et un bloc "try-catch" et un traitement pour essayer de réparer le problème.
• Si le processus métier est utilisé ailleurs dans l'application, il faudra le dupliquer dans un autre backing bean. On connait les problèmes liés à la duplication de code, principalement les problèmes liés à la maintenance de l'application : si le processus métier est modifié, il faudra modifier les différentes parties qui ont été dupliquées.