Déployer dynamiquement des extensions de classe
Je dois le reconnaitre, depuis la création d'arcOrama, on n'a pas beaucoup abordé les problématiques de développement alors qu'il y a pourtant beaucoup de sujets à traiter. Une publication récente sur ArcScripts m'a soufflé l'idée de revenir sur la notion d'extension de classe (ClassExtension en langage développeur) et sur les différentes options de déploiement envisageables.
Notion d'extension de classe
Il y a 10 ans, ESRI met au point la Géodatabase, point central de la gamme ArcGIS. Au delà du stockage de données spatiales dans des SGBD, la Géodatabase introduit une idée assez géniale qui consiste à pouvoir étendre les comportements des entités (features). C'est ce que permet de faire une ClassExtension en fournissant aux développeurs la possibilité de modifier le comportement des éléments d'une classe d'entités (points, lignes, polygones) ou d'une table. Les extensions de classes sont le moyen le plus simple et plus intégré à ArcGIS pour gérer des comportements spécifiques sur des objets métiers, notamment pour :
- appliquer des règles de validation complexes
(implémentation de IObjectClassValidation) - d'associer des actions spécifiques aux événements déclenchés lors de la mise à jour
(implémentation de IObjectClassEvents et IRelatedObjectClassEvents) - personnalisation de la boîte de dialogue des attributs
(implémentation de IObjectInspector) - personnalisation du rendu des entités d'une classe
(implémentation de IFeatureClassDraw) - automatisation de la création et de la préconfiguration de nouvelles tables ou de classes d'entités
(implémentation de IObjectClassDescription et IFeatureClassDescription)
Déploiement classique d'une extension de classe
Concrètement, une extension de classe est composant COM (sous la forme d'une dll) développé avec VB 6, Visual C++, VB .Net ou C#. Cette dll est associée à une classe d'entités ou à une table d'une Géodatabase. Le lien entre la dll et la classe d'entités repose sur le CLSID de la dll qui stocké dans la Géodatabase. Le déploiement de la ClassExtension se fait donc en distribuant la dll sur chaque poste client (ArcGIS Desktop, ArcGIS Engine ou ArcGIS Server).
L'inconvénient de cette méthode de déploiement réside dans le fait de devoir distribuer la dll sur chaque poste. Ceci peut s'avérer problématique si le déploiement doit se faire individuellement (c'est à dire non pas packagé dans une application) ou si de fréquentes mises à jours sont effectuées sur la dll.
Déploiement dynamique d'une extension de classe
L'arrivée du framework .Net 2.0 permet d'envisager une deuxième solution. En effet, en utilisant les fonctionnalités de compilation de code source à la volée de la librairie CodeDom, il devient possible de stocker le code source de l'extension de classe en base de données et de le compiler lors de l'utilisation de la classe d'entités. Il n'y a alors aucune dll à déployer car le code source est stocké de manière centralisée dans la Géodatabase.
Kirk Kuykendall a réalisé un prototype en .Net qui fait une belle démonstration de ce mécanisme en proposant sur le site ArcScripts un outil générique permettant de gérer dynamiquement une liste de plusieurs extensions classes. Cette liste d'extensions de classes est maintenue coté client par une extension de l'éditeur (EditorExtension). L'outil est fourni avec un exemple d'extension de classe, une Géodatabase et le code source de l'extension d'éditeur (VS 2005).
Déploiement dynamique d'une extension de classe
L'arrivée du framework .Net 2.0 permet d'envisager une deuxième solution. En effet, en utilisant les fonctionnalités de compilation de code source à la volée de la librairie CodeDom, il devient possible de stocker le code source de l'extension de classe en base de données et de le compiler lors de l'utilisation de la classe d'entités. Il n'y a alors aucune dll à déployer car le code source est stocké de manière centralisée dans la Géodatabase.
Kirk Kuykendall a réalisé un prototype en .Net qui fait une belle démonstration de ce mécanisme en proposant sur le site ArcScripts un outil générique permettant de gérer dynamiquement une liste de plusieurs extensions classes. Cette liste d'extensions de classes est maintenue coté client par une extension de l'éditeur (EditorExtension). L'outil est fourni avec un exemple d'extension de classe, une Géodatabase et le code source de l'extension d'éditeur (VS 2005).
J'ai testé l'outil sur plusieurs jeux de données et cela fonctionne bien. Si vous devez développer une application utilisant plusieurs extensions de classes, je vous conseille vivement d'étudier cette solution.
2 comments :
Très intéressant dans le cadre d'une transmission de la GDB à un client. Mais le .Net 2.0 n'est pas forcément installé sur leurs machines. Est-il un pre requis à l'installation d'ArcGIS 9.2 ?
Pascal
Bonjour,
Aucun framework .Net n'est nécessaire à l'installation d'ArcGIS 9.x en standard. Cependant, de nombreux outils complémentaires sont développés avec un langage .Net (VB ou C#) et nécessitent alors le framework 1.0, 1.1 ou 2.0 (selon les cas) pour leur déploiement. C'est par exemple le cas du mécanisme exposé dans cet article car il nécessite l'utilisation de la librairie Codecom présente uniquement depuis le framework 2.0 de .Net.
En espérant que cela vous aide à y voir plus clair.
Enregistrer un commentaire