Discussion :

[Alec6]

Alors voici:

Nous avons en gros:
- la couche IHM qui fait un premier controle sur le domaine de définition des inputs puis transmet les commandes CRUD ( Create, Update et Delete m'interessent particulièrement). Elle a aussi un grand role dans la cohérence des séquences d'appels à la couche métier (donc séquence de commande: par exemple on n'écrit pas un fichier avant de l'avoir créé). Ce controle masque souvent des manques de robustesse de la couche métier.

- la couche métier modifie le model de données et fait un certain nombres de controles de cohérence du model en rapport avec les contraintes métiers édictées par les spécifications. D'autres part elle lève des exceptions métier du genre (non on n'écrit pas dans un fichier avant de l'avoir créé)

- ici on a une couche DAO qui fait le passage Objet <--> (Tables,XML,TXT...).
Sa grande épreuve est de construire des graphes d'objets, en fonction des sollicitudes.

- ici une sous couche Controle objet de ma philo

- la couche persistance qui se démerde.

Si on remarque on a souvent un effet pyramidale en nombre de ligne de code à gérer et en complexité surtout (intellectuelle); avec du plus lourd vers le plus léger: IHM > Metier > DAO. (c'est pas toujours vrai)

Je me dit que ce qu'il faut défendre à tout prix c'est la cohérence de l'information persistée (cas d'un système d'information). Si une erreur est commise, pourra t-on réparer ? Va t-on perdre toute l'information , par ce que le logiciel plantera, au prochain démarrage...

Pour ce faire mon idée est que ma couche Controle vérifie l'information avant persistance, et même à la remontée pourquoi pas. Vérfier par rapport aux contraintes métiers: arité, dépendancces etc...
Alors bien sur la couche métier se doit de respecter les contraintes, mais cela est fait par un humain, et parfois même par un pingouin. Cette couche attaque le graphe d'objet par tout les sens et ne fait pas une vérification exhaustive de toute le graphe à chaque modification (ce serait long). Elle vérifie un simplement un sous graphe.

Une couche de controle des contraintes métier avant persistance serait peut être un vrai plus en terme de robustesse; à mon avis le rapport qualité/implémentation doit être élevé. Elle aurait pour but de parcourir tout le graphe et de vérifier les règles.

Qu'en pensez vous.

[Tommy31]

D'expérience, je dirais qu'il faut au maximum alléger les vérifications et les controles dans les basses couches, car ce sont celles qui sont appelées en derniers*, et plus on retarde la détection d'un problème plus il est difficile de l'endiguer. Et comme je suis partisan du modèle métier anémique...

En fait dans ton modèle métier tu défini les contraintes élémentaires assurant la cohésion structurelle: limitation des champs, test de vacuité, respect des cardinalités... Ce controle est garanti par la couche de persistence et remontée par les DAO.

Il faut bien utiliser les DAO, une transaction ne doit être commitée qu'à la réalisation atomique d'un service. Sinon, tu cours le risque d'avoir des incohérence.

Ensuite vient les couches services, tu n'en parle pas, je suppose que tu les fusionne avec les controleur ou alors que tu as enrichi le domaine pour assurer les fonctionnalités. Là, il y a plusieurs stratégies. La plus simple, c'est de raisonner en pré-condition, post-condition et invariants. Tu garni ta fonction d'un certain nombre d'assertions de façon à ce que tu couvre un certain nombre d'hypothèse sous lesquelles tu garanti un exécution correcte.

Le raffinement ultime, ca reste vraissemblablement la solution a base d'aspects, basé sur un moteur d'inférence style drools. Tu code ta logique métier dans le moteur (avec des dsl idoine ca le fait facilement), et tu applique des aspect pour réaliser la supervision (classiquement par interception around). L'intérêt d'une telle méthode, outre d'avoir la puissance d'un business rule engine, c'est la transversalité: le code de supervision est séparé du reste. D'ailleurs sa mise en service peut se faire simplement par configuration.

[Alec6]

Merci pour ta réponse, je vais préciser.

Mais en faite, mon problème vient surtout que si ma couche persistance est modélisée de façon générique, donc qu'elle ne permet pas de vérifier la cohérance du model face aux contraintes métiers.

Par exemple, j'ai un fait une table produit dans ma DB. Certains produits sont des services qui s'appliques à d'autres produits. En somme il y a des liens entre les instances des produits. Par exemple un produit voiture peut etre lié à un produit radio, camion à radio aussi, mais pas voiture à camion. J'ai donc un graphe d'objets produits (au sens mathématique, avec les éléments dans le même ensemble)

Cette contrainte (le lien voiture-camion n'est pas possible), et est normalement vérifiée:
- dans la couche IHM: car graphiquement on empeche le lien
- dans la couche business (normalement) si je travaille avec des Objets Voiture, Camion, et Radio qui héritent de produit, car je peux mettre un controle dans les setters des objets
- dans la couche DAO peut etre (je suis pas certain que ca soit son rôle)
- dans la couche persistance si je travaille avec des objets typées genre les tables Voiture, Camion, Radio; mais mon choix est de travailler avec des produits pour etre évolutif sans toucher la base (à ce que j'ai compris quand on fait une base il faut etre basique en conception, pas d'abstration, mais bon...).

En base de données j'ai donc la représentation d'un graphe d'objets produits (en relation les uns avec les autres). Mais tout produit, ne peut pas être lié avec n'importe quel autre selon mon commerce.

Donc le retour à ma question c'est comment s'assurer de la cohérence de ce graphe. Est ce que parcourir ce graphe entre DAO et Persistance, n'est pas une solution de qualité, de faible cout et efficace ?

[Tommy31]

Par exemple, j'ai un fait une table produit dans ma DB. Certains produits sont des services qui s'appliques à d'autres produits. En somme il y a des liens entre les instances des produits. Par exemple un produit voiture peut etre lié à un produit radio, camion à radio aussi, mais pas voiture à camion. J'ai donc un graphe d'objets produits (au sens mathématique, avec les éléments dans le même ensemble)

Ok, en fait tu as défini une classe produit abstraite dont hérite d'un degré tous les produits concrets : voiture, radio... Les liens sont définis par le type le plus générique, ce qui n'interdit pas une voiture d'être liée a un camion.
Ca c'est quelque chose que tu peux contraindre en modifiant ton modèle de donnée pour que sa taxonomie reflète mieux la réalité: voiture et camion devrait avoir un ancêtre commun par exemple véhicule qui lui même hérite de produit. Pareil pour radio qui hérite d'appareil qui hérite de produit. Ainsi, véhicule possède des liens vers des appareils mais jamais vers d'autres véhicules.

Bon, bien évidemment, il y a des cas ou cela n'est pas possible, ou alors ca charge trop la hiérarchie.

Pour répondre a ta question, tu peux implémenter ca dans les dao, mais ce n'est que de la programmation défensive, au même titre que des asserts en prologue de méthode. C'est quelque chose qui se débraye en production.

[Alec6]

Merci bien pour ta réponse.

La mon idée à tout son sens en faite c'est quand on fait un module générique de facture, avec les produits etc...