![Citation](https://forum.developpez.be/images/misc/quote_icon.png)
Envoyé par
jmguiche
Je pense, d'après mon experience, que la POO n'est globalement pas adaptée à l'informatique de gestion.
De temps en temps, elle peut participer à la résolution des problèmes.
Utilisée systématiquement, elle augmente les coûts de dév, le volume de code etc.
Je constate que l'approche "le métier" doit être dans un server d'application objet et tout ce qui fait "du métier" doit passer par là est une approche plus handicapante (coût, performances, etc.) et rigide qu'autre chose.
Quand en plus on oppose tout ça à une approche "thick DB", on obtient des éléments de comparaison interressant. C'est pour ça que je dis "d'après mon experience" et "je constate".
Je ne suis pas très loin de penser cela, mais dans un contexte totalement différent ...
Je suis actuellement dans un environnement Mainframe ( IBM z/OS et DB2 ) et chez nous s'opposent :
- une architecture actuelle "classique" à deux couches :
1) IHM (typiquement un navigateur) sur le poste de travail
2) moniteur transactionnel IMS/TM sur le mainframe avec des programmes écrits en COBOL et des accés SQL intégrés
Le lien étant fait par un "middleware" maison de type CORBA
- une architecture future à trois couches :
1) IHM (typiquement un navigateur) sur le poste de travail
2) serveur de type Websphere avec des programmes écrits en JAVA qui détiennent les règles "métier"
3) procédures stockées sur le DB2 z/OS pour l'accès aux données
La faisabilité et les performances de l'architecture à trois couches me semblent vraiment problématiques ...
Partager