Discussion :

[TrollMaster]

Bonjour,

Pour la plupart des projets sur lesquels je travailles nous essayons de respecter un ensemble de règles pour maîtriser au mieux les risques technologiques liés aux applications web 3 tiers :

A) Gestion Transactionnelle des Processus

Définition :
Assurer l’annulation d’un processus complet en cas d’échec d’une partie du processus

Pourquoi ?
 Laisser un état stable des données en cas de problème matériel
 Eviter l’effet boule de neige des anomalies

B) Gestion des Accès Concurrents

Définition :
Assurer qu’une même information ne soit pas modifiée par deux utilisateurs en même temps afin que les modifications utilisateur soient effectuées en prenant en compte des données réelles.

Pourquoi ?
 Considéré comme dû par le client
 Intégration quasi impossible en fin de projet

C) Gestion de la Propagation des Exceptions

Définition :
Les exceptions doivent être propagées de couche en couche pour être traitées de façon uniforme par un composant de gestion des exceptions. Les exceptions de type fonctionnelle et inattendues doivent être traitées de façon indépendante.

Pourquoi ?
 Faciliter la correction en service régulier
 Pouvoir gérer différents types de restitution des exceptions (mail, écran)

D) Utiliser un Maximum de Données Réelles

Définition :
Ne pas utiliser de systèmes de cache désynchronisés de la base de données pour les données fréquemment modifiées.

Pourquoi ?
 Eviter de présenter des données fantôme
 Laisser la base gérer les accès concurrents

 Toléré pour les données référentielles

E) Isoler les Sous-Systèmes Techniques

Définition :
Un sous-système technique assure une fonction transversale pour l’application et différentes implémentations peuvent convenir (Accès aux données, Log, Authentification, Reporting)

Pourquoi ?
 Maîtriser les variations de l’implémentation de ces sous-systèmes
 Intégrer des Framework Techniques dans les applications

F) Minimiser les dépendances entre objets

Définition :
Les dépendances entre objets (ou couplage) sont forts lorsque la modification d’un objet impacte fortement les autres objets en relation

Pourquoi ?
 Maîtriser le périmètre des évolutions
 Séparer l’application en modules pouvant évoluer séparément

G) Responsabiliser les objets

Définition :
Un objet doit être responsable d’un périmètre défini et être le seul à en être responsable (principe de cohésion).

Pourquoi ?
 Maîtriser le périmètre des évolutions
 Permet la réutilisation


Qu'en pensez-vous ?

[ego]

Ben c'est plus bien tout cela.
Vous n'avez plus qu'à utiliser Spring pour voir comment facilement mettre en place tous ces principes. Bon ok, peut-être que Spring n'est pas adapté à votre situation mais si vous faites du Java, je ne vois pas pourquoi cela serait le cas (à moins d'avoir un truc maison similaire)

[Hephaistos007]

Ce sont les bonnes pratiques. Difficile de vous contredire.

Les conteneurs d'exécution (ex:J2EE) servent mettre en oeuvre tout cela plus facilement, permettant de vous concentrer d'avantage sur la logique métier.

[TrollMaster]

Je ne souhaites pas entrer dans des détails d'implémentation (Spring) ou de langage (Java). J'aimerai enrichir la liste précédente de règles me permettant de valider un prototype d'architecture en vue de son industrialisation MDA. Auriez -vous des idées de règles permettant de maîtriser les risques technologiques tels que les variations de spécifications.

[Hephaistos007]

Dans ce cas tu oublies un point crucial :

La séparation du modèle metier de la plateforme technique. Il s'agit de fournir la description du modèle métier d'une part, ET de la description de la plateforme technique d'autre part. C'est cela l'approche MDA.

[TrollMaster]

Je prends un raccorci concernant la modélisation métier. Je fais le choix de créer un composant métier et un DTO par entité du modèle. Dans la plupart des cas celà suffit pour modéliser le métier. Les processus CRUD sont réalisés par les composants. Des services orchestrent l'exécution des composants pour les processus métiers plus complexes.

[ego]

J'aimerai enrichir la liste précédente de règles me permettant de valider un prototype d'architecture en vue de son industrialisation MDA.

Les règles que tu as énoncé ne permettent en rien de valider un proto d'archi pour une industrialisation MDA. Tu as énoncé des principes généraux qui n'ont rien à voir avec MDA. Tu peux tout à fait faire un sac de noeuds avec l'approche MDA. Ce qu'il faut faire quand on veut se lancer dans du MDA, c'est aller beaucoup plus loin dans les règles et définir le framework technique sur lequel tu vas t'appuyer puis ensuite définir les règles de transformation.

Auriez -vous des idées de règles permettant de maîtriser les risques technologiques tels que les variations de spécifications.

ça c'est un peu l'esperanto. Disons que la séparation en couches, la définition claire des responsabilités (et pas trop de responsabilité), la forte cohésion et le faible couplage permettent de se prémunir d'éventuelles évolutions. Mais comme tu le vois dans ma phrase, je n'énonce que des généralités. Il y a bien qq métriques qui donnent le degré de cohésion et le niveau de couplage (package, classe) mais ensuite à toi de te fixer des niveaux acceptables.
Une autre bonne idée et de se poser la question "Et si finalement on faisait ça, le truc qu'ils ont dit que l'on ne ferait jamais ? Quels impacts cela aurait sur mon architecture ?".

Enfin, pour se prémunir des modif de spéc. il faut avant tout être AGILE !! (oui oui c'est à la mode en ce moment mais il y a du vrai ou tout au moins, il faut interpréter l'agilité, ici, comme un constat qu'on ne peut pas tout prévoir techniquement, donc il faut savoir se réorganiser)

[TrollMaster]

Je suis heureux de ta réponse. Je suis tout à fait d'accord avec toi pour aller plus loin. En fait voici ma démarche pour mieux comprendre mon propos :

Je travailles dans une SSII et voici l'inusable paradoxe source de bien des maux : former des débutants sur des forfaits tout en maitenant une productivité minimum. Je ne compte plus les projets plantés par une équipe inexpérimentée techniquement. Ce n'est pas un reproche mais une constatation alors comment faire ?

Je propose d'attaquer le taureau par les cornes et de fournir un modèle d'architecture réutilisable d'un projet à un autre. Cette architecture réutilisable doit prendre en compte la maîtrise des règles énoncées auparavant dans le but de maîtriser les risques technologiques. Comme tu dis on me paut pas tout prévoir mais on peut quand même limiter les impacts

L'architecture que j'ai mise en place maintenant sur 6 projets client me permet de former les débutants aux bonnes pratiques de conception objet et à la manipulation de DAO d'un Framework de Persistance (Ibatis en l'occurence). Une solution d'ihm est proposée et peût être adaptée au besoin.

Ce n'est pas la solution idéale mais cela permet de former les personnes et d'orienter les discussions sur le niveau conception et pas comment écrire un service métier mais POURQUOI !!!!!!!!!!!

Je cherche donc à préciser mes règles pour afiner le modèle.

En ce qui concerne le MDA. C'est pour moi inaccessible car improductif.
Je fonctionne plutôt de la façon suivante :

1) Prototype CRUD à valider par le client pour la gestion d'une entité du modèle
2) Création de templates XSL à partir du prototype
3) Industrialisation du code par rapport au modèle dans mon logiciel de génération de sources
4) Adaptation des besoins fonctionnels client.

Ma démarche ressemble plus à 2TUP.

Je suis également curieux de connaître vous méthodes d'industrialisation si vous en utilisez.

[ego]

Très bonne démarche.
L'idée est effectivement de fournir un cadre le plus structurant possible, que ce soit au niveau des frameworks, du cadrage de leur utilisation mais aussi au niveau de l'environnement de développement et l'organisation des "projets" et du process de build/déploiement.
A une certaine époque, j'avais standardisé l'environnement de développement sur la base de script ANT et de templates de "projets" un peu comme cela existe maintenant avec Maven ou la notion de projet sous Eclipse.

Bref, fournir un cadre pour faciliter l'insertion et une très bonne chose.
As-tu regardé Spring ? C'est vraiment excellent pour fournir un cadre standard et de bonnes règles de base.

[Ismail.h]

Bonjour :

Ceci est mon premier poste sur ce forum,et je trouve trés intéressant tous les themes ici traités.

Pour revenir au sujet du thread,je retient des prerequis de sun sur les capabilités d'une architecture multicouche les points suivants :

*Disponiblité
*Fiabilité
*Securité
*Fiabilité
*Manageabilité
*Flexibilité
*Performance
*Scalabilité
*Validité
*Reutilisabilité
*Capacité

Donc autant de points a prendre en compte lors de la conception d'une aplication web.

[Immobilis]

A) Gestion Transactionnelle des Processus
B) Gestion des Accès Concurrents
C) Gestion de la Propagation des Exceptions
D) Utiliser un Maximum de Données Réelles
E) Isoler les Sous-Systèmes Techniques
F) Minimiser les dépendances entre objets
G) Responsabiliser les objets
Qu'en pensez-vous ?

Salut,

J'aimerai bien rentrer un peu dans les détails des points énoncés:

• Gestion Transactionnelle des Processus
  Cela pose la question de savoir quelle couche a la connexion en main. Est-ce la BLL ou la DAL? Actuellement, j'utilise la DAL mais penche de plus en plus pour la BLL. En effet, disons que la validation d'une vente nécessite l'utilisation d'au moins deux processus métier: l'enregistrement de l'acte d'achat et le destockage de l'article. J'appellerai donc par exemple :
  

  Code :

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

  1
  2
  3
  4
  5
  6
  BLL.Vente.Create(Achat)
        BLL.Achat.Create(Achat)
             DAL.Achat.Create(Achat)
        BLL.Stock.Update(Achat)
             DAL.Stock.Update(Achat)

  Ces deux étapes doivent être accomplies pour valier ma transaction. Si la connexion est gérée par la DAL elle ne peut pas etre partagée entre DAL.Achat et DAL.Stock. A moins de faire:
  

  Code :

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

  1
  2
  3
  4
  BLL.Vente.Create(Achat)
        DAL.Vente.Create(Achat)
             DAL.Achat.Create(Achat)
             DAL.Stock.Update(Achat)

  Mais on introduit du métier dans la DAL.
  Mon idée serait:
  
  

  Code :

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

  1
  2
  3
  4
  5
  6
  7
  8
  BLL.Vente.Create(Achat)
        new DataAccessObject
        DataAccessObject.BeginTransaction
        BLL.Achat.Create(Achat, DataAccessObject)
              DAL.Achat.Create(Achat, DataAccessObject)
        BLL.Stock.Update(Achat, DataAccessObject)
              DAL.Stock.Update(Achat, DataAccessObject)
        DataAccessObject.Commit

• Gestion des Accès Concurrents
  Cela est géré par la requête SQL en définissant l'isolation de la transaction. Je dirais que par défaut, il faut que la requête ne tienne pas compte des accès concurrents (les requêtes SELECT) sauf mises à jour de la base, dans le cadre d'une transaction par exemple (UPDATE, INSERT, DELETE). La plupart du temps les informations remontées de la base n'ont pas besoin d'être les plus à jour. En ne tenant pas compte des accès concurrents, on ne pose pas de verrou sur l'enregistrement et la lecture est beaucoup plus rapide.
• Gestion de la Propagation des Exceptions
  Important en effet. Personnellement, voici comment je fais: http://www.developpez.net/forums/d70...e/#post4081168
• Utiliser un Maximum de Données Réelles
  Boaf, j'inverserais plutôt en disant utiliser un maximum de données "cachées" et les rafrîchir quand c'est vraiment nécessaire. Cette approche à au moins l'avantage de poser la question de la persistance des données. Cela soulage d'autant la base de données qui n'a pas à reservir des brouettes de champs de descriptions qui ne changent qu'une fois par an.
• Isoler les Sous-Systèmes Techniques
  Oui, si je comprend bien je l'ai fait pour mon accès aux données et mon getionnaire d'erreurs
• Minimiser les dépendances entre objets
  Oui, faible couplage. Faire en sorte qu'un objet ne traite que les données de son périmètre. En fait, faites des objets feinéants. Qu'ils en fassent le moins possible.
• Responsabiliser les objets
  Découle du point précédent

Pouvez vous reprendre les points et détailler votre façon de le mettre en pratique?

A+

[chaplin]

Gestion Transactionnelle des Processus
Cela pose la question de savoir quelle couche a la connexion en main. Est-ce la BLL ou la DAL? Actuellement, j'utilise la DAL mais penche de plus en plus pour la BLL.

Je suis entrain de fouiner dans NHibernate, c'est pas ça que tu cherches par hasard.

[Immobilis]

Passer par NHibernate pour gérer l'accès aux données? Il est aussi possible d'utiliser Le Framework pour travailler avec des sources de données liées avec des objets métier. Quelles différences fais-tu entre les deux?

A+

[chaplin]

J'ai trouvé les System.transactions dans ADO.NET 2.0