Discussion :

[elitost]

Bonjour,

Une question qui va je le souhaite aboutir à un débat constructif.

Je travaille actuellement dans une entité où nous nous appuyons sur des données stockées sous Oracle, et plusieurs applications satellites utilisent ces données.

Les langages de ces applications sont hétérogènes, Java, .Net, ColdFusion...

Nous nous posons actuellement la question concernant la logique métier, où la positionner ?

En base de données (triggers, procédures stockées, fonctions...) ?
Dans un tiers applicatif entre Oracle et les IHM ?
Dans le client (ex: javascript dans le navigateur ) ?

C'est un gros débat, une guerre de positions, bcp d'arguments existent pour ou contre chacune des solutions, et bien souvent ça dépend de l'architecture en place

J'aurais aimé lire vos arguments et idées sur la question...

Merci d'avance

[kisitomomotene]

chaque architecture a ses avantages et inconvénients.
logique métier dans la base de donnée:
avantages:
- meilleurs performances
- les procèdures stockées étant compilées, certaines erreurs SQL sont détectées très tôt.
- La base de donnée étant l'ultime point de consolidation des données, placé certaine logique dans la base de donnée permet de mieux renforcer le contrôle de certaines contraintes applicatives, quelque soit les applications utilisant ces données.
-déployement relativement aisé en cas de mise à jour de la logique métier
- Administration et maintenance centralisées, donc simplifiées

inconvénients:
- solution non portable d'une base de donnée à l'autre
- les langages de procèdures stockés sont non orientés object, pauvre en framework de developpement, par consèquent sont difficilement maintenables ( là je parle avec reserve)
- solution gérant très difficilement la montée en charge
- Le niveau de sécurité dépend du SGBD.

logique métier dans les serveurs d'applications:

avantages:

- portable d'un bd à l'autre
- gestion de la sécurité et des transactions renforcées (transaction impliquant plusieurs BD et autre ressource transactionelle comme les message queue), et indépendant des BD.
- richesses des langages, frameworks de développement=> meilleur maintenabilité, et fiabilité
- bonne gestion de la montée en charge.
- déployment aisé: aucune installation sur le poste client (dans le cas où on utilise le Web (Ajax/HTML/Applet etc.) ou javawebstart comme technologie)
- Administration et maintenance centralisées, donc simplifiées

inconvénients:
- mauvaises performances.

logique métier sur le poste client

avantages
- portable d'une BD à l'autre
- richesses des langages, frameworks de développement=> bonne maintenabilité, et fiabilité

inconvénients

- Mauvaise prise en charge de la sécurité et des transactions.
-déployements plus difficiles
- Administration et maintenance decentralisées, donc plus compliquées

[wiztricks]

je plusse l'argumentaire de kisitomomotene

Il me semble peu judicieux de mettre la logique métier dans les clients surtout avec un héritage aussi varié.

Ce qui signifie de l'implémenter "plus bas".
Et si on lit l'argumentaire de kisitomomotene, il est clair qu'il n'est pas raisonnable de tout miser sur les serveurs d'applications ou sur le SGDB.

Donc coder la logique métier dans les serveurs d'applications sans s'interdire de faire faire certains traitements par des procédures stockées en base.
- W

[hed62]

Je suis entièrement d'accord, et apporterais ma précision ainsi :

Tout ce qui est critique doit etre fait au plus bas (pour être certain que le test soit fait par exemple).
A contrario, les tests bonus (du genre "appeler le service X avec la donnée Y mais sans la donnée Z est inutile") peuvent être fait au niveau serveur d'application, voire client si on en est capable (griser le bouton si la textbox n'est pas renseignée...)

[souviron34]

de politique, en tenant compte des arguments ci-dessus, moi mon choix est fait :

Certainement pas dans la BD. Le moteur peut changer, d'autres paramètres ou modifications de la logique métier (par exemple lois, normes, précisions, etc) peuvent apparaître, et tenir une compatibilité quand une BD est modifiée dans son fondement (par exemple pouvoir continuer avec le même soft à lire les archives) est vouée à l'échec..

L'hétérogénéité des langages n'a que peu de rapport avec le fond du problème. La plupart des langages peuvent comnuniqer entre eux.

Ce qui est important est :

L'hétérogénétité des applications.

• Si il y a beaucoup d'applications accèdant à la même logique métier, alors elle devra être dans les serveurs
• Si il y a peu d'applications partageant la même logique métier, mais beaucoup partageant les mêmes données, alors la logique sera dans les applis.

Pensez à la maintenance et l'évolutivité...