> Tech > Simplifier la reconception des applications

Simplifier la reconception des applications

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

par Sharon L. Hoffman - Mis en ligne le 26/05/2003
La restructuration est généralement la première étape de tout projet de modernisation d'applications et il est souhaitable de la terminer avant d'entreprendre d'autres actions comme la création de nouvelles interfaces utilisateur. Diverses stratégies et terminologies s'appliquent à  cette phase de la reconception. Ainsi, la mise en oeuvre d'un modèle de conception MVC (Model-View-Controller) est en vogue en ce moment.

Le principe sous-jacent du processus de restructuration est toujours le même. Les développeurs visent une architecture qui divise l'application en ses parties constituantes (interface utilisateur, logique de gestion, par exemple) avec des mécanismes de communication clairement définis permettant l'interaction entre les différentes portions de l'application. Bien qu'on puisse restructurer des applications avec n'importe quel langage de programmation, c'est plus facile avec certains outils et techniques. Nous verrons ici quand et comment il faut utiliser les triggers et les contraintes, ainsi que certains des écueils à  éviter. Nous verrons également les procédures stockées et l'utilisation de XML pour définir les interfaces entre les composants de l'application.

Simplifier la reconception des applications

Il existe des techniques permettant de relier
directement la logique de gestion à 
l’activité de base de données et les dispositifs
OS/400 les plus mystérieux dans ce
domaine sont les triggers et les
contraintes. Un trigger est un programme
lancé automatiquement en réaction
à  un événement de base de données
particulier (insertion, mise à  jour ou suppression)
pour un fichier spécifique. Une
contrainte est une règle d’intégrité des données imposée par la gestion de la
base de données.

Les triggers et les contraintes ne sont
pas nouveaux en OS/400 (ils figuraient
déjà  dans la V3R1). Ils ne sont pas non
plus propres à  l’iSeries. Ces deux dispositifs
donnent aux développeurs la possibilité
de restructurer des applications tout
en réduisant le code redondant et en assurant
l’intégrité des données. Si vous décidez
de reconcevoir vos applications
existantes ou si vous en créez de nouvelles
selon une approche MVC, ces techniques
méritent considération.

La prise en charge des triggers par
l’OS/400 se divise en deux catégories générales:
(1) les triggers externes mis en
oeuvre à  l’aide de CL (il n’y a pas de support
DDS pour les triggers ou les
contraintes) et (2) les triggers SQL, qui firent
leur apparition en V5R1. Bien que la
plupart des développeurs iSeries
connaissent probablement mieux les triggers
externes, leurs homologues SQL présentent trois avantages: meilleure granularité,
implémentation standard, et
documentation plus facile.

Téléchargez cette ressource

Guide de réponse aux incidents de cybersécurité

Guide de réponse aux incidents de cybersécurité

Le National Institute of Standards and Technology (NIST) propose un guide complet pour mettre en place un plan de réponse aux incidents de cybersécurité, nous en avons extrait et détaillé les points essentiels dans ce guide. Découvrez les 6 étapes clés d'un plan de réponse efficace aux incidents de cybersécurité.

Tech - Par iTPro.fr - Publié le 24 juin 2010

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT