Or, qu'est ce qu'une Dll ISapi sinon qu'un programme qui receuille des informations (requêtes) depuis un serveur Web, qui les traite (comme un programme classique) et qui retourne (éventuellement) un résultat ?

La réponse se trouve dans la question : Un programme.

Pour illustrer nos propos, nous vous fournissons deux exemples, une gestion de caddy et une expédition de Mails. Si le caddy est d'une utilisation limitée dans un programme (encore que cela reste à prouver), l'expédition de mail est utilisée et utilisable dans tous les contextes.

Nous avons donc commencé par bâtir un objet Metier (un pour le caddy, un pour le Mail)

Pour débugger ces objets, nous avons ensuite créé une application windows "classique". Au dela du fait que l'application, peut servir, cette méthode permet de finaliser la construction de l'objet sans avoir a supporter la délicatesse du debuggage d'application dans les contextes (et la multiplicité des méthodes selon le contexte) divers et variés.

Une fois les objets considérés comme satisfaisant, nous avons souhaité développer un objet CustomIsapi. L'idée était de faire un objet qui nous iaderait à accélerer le développement de nos applications ISAPI en réunissant les méthodes courement utilisées dans une application de ce type. Lors de l'étude, nous avons considéré, qu'il était souhaitable de dissocier les méthodes pouvant servir à n'importe quelle Dll Web (ISAPI et/ou ASP) que nous avons réuni dans l'objet CustomDllObject et nous avons créé un descendant du nom de CustomIsapi.

Il nous restait plus qu'à écrire un objet " de contexte " qui s'interface avec nos objets génériques et objets métiers.

La première réaction serait probablement de commencer à coder dans le webModule. A notre avis, ce type de réaction est à éviter. Il est hautement préférable de faire un nouvel objet, descendant de CustomIsapi, qui encapsule l'objet métier (Caddy ou Mail dans notre exemple).

Pourquoi ?

Pour plusieurs raisons !

En premier lieu, si vous avez bien compris le fonctionnement du WebModule, vous avez noté que pour profiter du pooling de connexion, il est très peu recommandé de déclarer des variables de portée WebModule. Ce qui limite grandement les possibilités, sauf à écrire des action de 500 lignes, peu lisibles et sources de difficulté de lecture, de maintenance.

En second lieu, vous vous priveriez des méthodes définies dans nos objets génériques, ou leur utilité serait moindre.

En troisième lieu, si vous devez réécrire le même type d'application, vous allez naturellement réutiliser le premier webmodule, alors même qu'il peut contenir d'autres actions qui n'ont rien à voir avec le nouveau projet. Au bout de cinq ou six projets, vous aurrez 4 ou cinq fois à peu près le même code dans différentes unités... Pas très productif...

Enfin, moins vous écrivez de code dans vos webModule, plus ils sont faciles à lire et à maintenir.

Voici donc les objets TCaddyISAPI et TMailISAPI

et voici le code de nos WebModules MainMail et MainCaddy qui tiennent en quelques lignes

Schéma fonctionnel

      TCustomDllObject
	|
      TcustomIsapi
	|
      TCaddyIsapi - TCustomCaddy - Appli Windows
  

   TCustomDllObject
	|
   TcustomIsapi
	|
   TMailIsapi - TCustomMail - Appli Windows
    

Il nous restait à écrire l'interface pour créer le composant ASP ASP_SendMail (à vous d'écrire celle pour Caddy, ou d'utiliser le Caddy ASP que nous fournissons par ailleurs)

Avantages de la méthode

Un code portable, facile à débugger, à la maintenance facilitée. Si vous savez faire du delphi (ce dont je ne doute pas), vous savez maintenant développer quelque soit le contexte.

Bon développement