Si le concepteur trouvera dans DotNetNuke une panoplie d’options facilitant la création de sites Web riches et variés, le développeur y trouvera également un ensemble d’outils pour faciliter la réalisation d’applications complexes, complétées par une large panoplie d’extensions génériques connues de l’architecte et du directeur de projet DotNetNuke.

L’ensemble de ces outils se regroupe sous la notion générale d’API (Application Programing Interface) mais on peut les classer selon plusieurs axes de différentiation:

Leur utilité

• Le noyau de DotNetNuke possède un certain nombre de fonctionnalités générales et réutilisables,
• Son modèle applicatif permet l’intégration d’extensions spécifiques, comme les modules, les thèmes graphiques, les providers etc. 

En d’autres termes, on peut distinguer les composants qui servent à construire DotNetNuke et peuvent être réutilisés pour construire d’autres choses, de ceux qui servent à intégrer un composant nouveau au sein de DotNetNuke.

Il existe également un certain nombre d’éléments qui possèdent simultanément ces deux attributs, comme par exemple les interfaces publiques de module : Il s’agit là pour le développeur de respecter optionnellement un "contrat d’intégration" sous forme d’une interface à implémenter, en échange de quoi DotNetNuke enrichit le module d’une fonctionnalité supplémentaire comme par exemple la portabilité ou l’indexation du contenu.

Leur nature

• Un certain nombre de ressources sont destinées au navigateur client (images, JavaScript, Html, css). Une bonne partie de ces ressources s’adresse à des profils de type designer/graphiste/intégrateur xHtml.
• D’autres sont traitées par le serveur web (Formulaires, contrôles, contrôleurs métiers), ou le serveur de données (procédures stockées). La majorité de ces ressources s’adressent à des profils de type Développeur/Architecte/DbA/Intégrateur applicatif.

La encore, un certain nombre d’éléments se situent à la frontière (API cliente et JavaScript, Skinning des contrôles et des formulaires), et seront généralement le lieu d’interactivité entre des domaines d’expertise qui peuvent être par ailleurs largement séparés.

Dans tous les cas, l’administrateur système pourra s’appuyer sur le options de paramétrage adossées à l’API, éditables en ligne, dans les fichiers de configuration des composant DotNetNuke, ou dans le paramétrage du serveur web et du moteur ASP.Net.

Leur type

Muni des deux axes de différentiation précédents, on peut enfin s’intéresser à la hiérarchie principale selon laquelle DotNetNuke définit son modèle et son extensibilité.

Depuis la version 5, cette hiérarchie a été uniformisée de sorte qu’elle correspond généralement aux différents types d’extensions qu’il est possible de déployer ou de commercialiser selon des principes de packaging universel.
Un package se présente sous la forme d’un fichier zip contenant un fichier manifeste de déclaration au format Xml et l’ensemble des autres ressources spécifiques (Contrôles, traductions, styles ...).

Les principaux types d’extensions qu’on peut concevoir sous DotNetNuke sont les suivants :

• Thèmes graphiques ← API de skinning DotNetNuke)

  • Manifestes Xml de déclaration (depuis la V5)
  • Thèmes de page (Html + XML ou .ascx)
    ou
    Containers de module (Html + XML ou .ascx)
  • Skin Objects
  • Scripts
    • Spécifiques
    • APIs (jQuery, ASP.Net Ajax, API DotNetNuke…)
  • Ressources
    • Présentation (css, images, medias, documents)
    • Traductions (Resx)

• Modules et Skin Objects ← API de modules DotNetNuke)

  • Manifestes de déclaration (Définition)
  • Formulaires
  • Couche applicative
  • Couche d’accès aux données (DAL)
  • Scripts
  • Resources

• Providers ← Providers abstraits DotNetNuke)

  • Manifestes de déclaration
  • Implémentation concrête
  • Paramètres de configuration

• Composants d’authentification ← Structure hybride à mi-chemin entre module et provider ) 

  • Manifestes de déclaration
  • Formulaires
  • Couche applicative
  •  Ressources (Resx de traduction, css, js, swf etc.)

• Pack de langue ← Composants consommant des ressources de traduction ) 

  • Manifestes de déclaration
  • Fichiers Resx de traduction

• Portails packagés ← Composant d’import/export de portails/pages/modules ) 

  • Manifestes de déclaration
  • Export Xml du portail (Paramètres, pages, modules etc.)
  • Fichiers de ressources du portail zippées

Un ensemble de conventions parfois implicites permet de détailler la décomposition de ces types, et par exemple la plupart des modules applicatifs suivent le modèle suivant:

• Manifeste .DotNetNuke de Définition

• Couche de présentation

  • Formulaires principaux
    • Design
    • Evénementiel (Code Behind)
  • Bibliothèque de contrôles
    • Design
    • Code Behind
  • Scripts
  • Ressources (module.css, images)

• Couche métier

  • Entités
    • Entités métiers
    • Entités de paramétrage
  • Contrôleurs
    • Contrôleurs d’entités
    • Contrôleurs de services
    • Contrôleurs principal: Interfaces publiques DotNetNuke
  • Services
    • Librairies externes
    • Services web
    • Helpers DotNetNuke

• Couche de données

  • Composants applicatifs
    • Fournisseur abstrait
    • Fournisseur hérité
    • Helpers additionnels
  • Scripts SQL (schémas + procédures stockées)
    • Scripts d’installation
    • Scripts de montée de version
    • Scripts de désinstallation

L’une des difficultés principales d’un développeur découvrant DotNetNuke est la détermination au sein des exemples qu’il étudie ce qui est nécessaire, de ce qui est de l’ordre de conventions diverses et qu’il peut parfaitement omettre de suivre à la lettre. C’est particulièrement vrai quand il ne s’agit pas de concevoir un module commercial mais plutôt de réaliser une application ASP.Net spécifique voire dédiée.

 Par exemple, DotNetNuke propose pour les couches d’accès aux données un modèle par fournisseur un peu contraignant conçu pour permettre la commercialisation de modules multi-SGBD. Si comme la plupart du temps, il n’est pas prévu de supporter d’autres bases que Sql Server, ce modèle peut être largement court-circuité et une couche d’accès spécifique utilisant un ORM du marché peut être mise en place comme dans n’importe quelle application ASP.Net.

Il faudra considérer DotNetNuke dans ce cas comme une application ASP.Net habituelle et s’autoriser à intégrer au besoins des librairies de contrôles et de composants internes ou externes, des composants additionnels de type HttpModules, HttpHandlers, Control Adapters etc. Il s’agira simplement d’éviter de modifier le noyau pour s’autoriser des montées de version ultérieures, ce qui pose rarement un problème compte tenu du caractère extensible de DotNetNuke et du modèle ASP.Net sous jacent.

On peut enfin en guise d’introduction, décrire la structure de l’API offerte par DotNetNuke pour la conception de modules applicatifs au développeur ASP.Net.

Le noyau DotNetNuke comprend les éléments suivants :

• Des librairies de support dont DotNetNuke dépend mais qui peuvent être réutilisées dans une autre application :
  • CountryListBox.dll : Support Geo IP
  • DotNetNuke.Syndication.dll : Support RSS
  • DotNetNuke.WebUtility.dll : API Cliente (interaction ASP.Net <-> JavaScript)
  • DotNetNuke.Controls.dll : Librairie de contrôles Ajax (similaire à l’Ajax Control Toolkit)
  • Les fichiers de scripts (répertoire \js) associées aux deux précédentes librairies, qui constituent un Framework à part entière à l’image de et adossé à jQuery et ASP.Net Ajax.
• Une librairie principale qui constitue le cœur de l’application : DotNetNuke.dll
  Celle-ci comprend de nombreuses classes qui s’organisent suivant une riche hiérarchie d’espaces de noms comprenant entre autre :
  • DotNetNuke.Common : Sorte de fourre-tout historique dans lequel il est parfois difficile de se retrouver, qui a été largement ventilé dans des espaces de noms plus spécifiques, mais qui reste fondamental pour :
    • Les fonctions statiques importantes : DotNetNuke.Common.Globals
    • La gestion du cache applicatif : DotNetNuke.Common.Utilities.DataCache
    • L’interaction System.IO <-> API de gestion de fichiers DotNetNuke : DotNetNuke.Common.Utilities.FileSystemUtils
    • L’hydratation d’objets métiers par Reflection DotNetNuke.Common.Utilities.CBO
    • Et puis tout un tat de petites choses qui méritent de savoir ce que cet espace de nom contient
  • DotNetNuke.ComponentModel : Cet espace de nom récent reçoit les types de base permettant l’instanciation et la manipulation des composants applicatifs.
  • DotNetNuke.Data.DataProvider : Cet énorme provider abstrait regroupe l’ensemble des méthodes assurant la communication de base avec la base de données
  • DotNetNuke.Entities : Il s’agit de la couche métier de base de DotNetNuke proposant des couples entités/contrôleur pour les tables principales de la base de données (paramètres Hôte, Portails, Pages (« Tabs »), Modules, Utilisateur etc.) Ces classes très importantes sont systématiquement utilisées pour interroger ou manipuler ces notions dans le code. On y distinguera 2 classes un peu particulières et également fondamentales :
    • DotNetNuke.Entities.Modules.PortalModuleBase : Il s’agit d’un contrôle abstrait, de la classe de base dont héritent tous les formulaires de modules DotNetNuke (remplacée depuis peu par l’interface IModuleControl pour plus de flexibilité). Elle fournit au développeur de module l’ensemble des informations permettant de situer le module courant, l’utilisateur courant, la page courante, etc.
    • DotNetNuke.Entities.PortalSettings : Contrairement à ce que son nom suggère Il ne s’agit pas tout à fait de la classe d’entité de portail (voir PortalInfo), mais plutôt de la classe représentant le contexte DotNetNuke d’une requête courante : similaire au contexte http (et d’ailleurs stockée dedans), elle fournit des informations d’environnement accessibles en l’absence d’une hiérarchie de contrôle.
  • DotNetNuke.Framework : Accueille certaines classes de base
    • Des Helpers permettant l’activation de composants externe et la manipulation des types et des objets
    • Les contrôles de base des pages et des user controls DotNetNuke
  • DotNetNuke.Modules fournit les classes de modules applicatifs et providers de services
  • DotNetNuke.Security contient des Helpers génériques et la couche métier des entités DotNetNuke de sécurisation.
  • DotNetNuke.Services fournit principalement les services génériques offerts par l’API (emails, planification, journalisation etc.) et pour ceux qui possèdent un helper historique dans DotNetNuke.Common la couche métier correspondante
  • DotNetNuke.UI regroupe tout ce qui concerne la couche de présentation à l’exception de quelques exceptions encore couvertes dans ce qui précède pour des raisons historiques. On y trouve
    • Les classes et contrôles de base DotNetNuke, ainsi que les contrôles réutilisables
    • Des Helpers généraux dont une partie de l’API cliente spécifique à DotNetNuke
• Les modules http et les providers instanciés sont compilés dans des assemblies propres, mais il est rare de les référencer puisqu’ils sont largement commandés depuis la librairie principale
• En revanche il est assez courant de référencer les assemblies d’extensions spécifiques pour en utiliser l’API spécifique.

Muni de l’ensemble des outils fournis par l’ API, le développeur DotNetNuke construit des packages proprement structurés et déclarés pour être déployés en ligne sur l’application.