July 30, 2009 5 min to read

nPress Architecture & Design

Architecture

La solution nPress est composée de trois projets :

• nPress.Core : contient tout ! En gros pour l'instant je ne cherche pas à multiplier les dll, et je ne découpe qu'en namespace/répertoire.
  • Controller : classes en rapport avec System.Web.Mvc.Controller
  • Entities : classes POCO qui représentent les entités du domain
  • Interfaces : différentes interfaces
  • Mapping : Mapping Fluent Nhibernate
  • Repositories : implémentations de IRepository
  • Routes : les Routes de System.Web.Routing
  • Services : Services du domaine
  • View : contrôles, helper, page, master page ... les vues MVC
• nPress.Tests : Contient les tests Nunit. L'organisation se rapprochera de celle de nPress.Core. Tous les tests devront passer sous Monodevelop ;)
• nPress.Web : Le site web de type MVC. A noter que tous les répertoires on été renommés sont Majuscule.
  • content : correspondra quasiment au répertoire wp-content de WordPress.
  • controllers : Les controllers MVC
  • les vues sont dans le répertoire themes.

Design

Je ne vais pas utiliser DDD dans ce projet. Il y a bien un repository mais, il ne correspond pas à celui que l’on trouve habituellement dans DDD. Le repository utilisé, sert d’abstraction sur la DAL. La DAL étant représentée par l’ORM ou un autre système (db4o) que l’on souhaite mettre en œuvre.

Le point d’entrée de l’application web MVC est le controller (je passe sur les routes). Le controller si il en a besoin, va faire appel à un service métier qui lui-même fera appel à un repository pour récupérer ou mettre à jour des données persistées. Le controller sélectionne ensuite une vue et l’affiche.

Ioc/DI

Pour casser la dépendance entre les services et le repository concret. Chaque repository devra implémenter une interface IRepository. Le repository concret utilisé sera ensuite chargé par le biais d’un moteur d’injection de dépendance. J’utilise ici AutoFac. Je devais utiliser StructureMap, mais suite à la mise à jour de Nhibernate en version 2.1, une erreur est apparu. Je n’ai pas vraiment le temps de déboguer les sources de StructureMap, j’ai donc simplement changé le moteur pour un autre tout aussi bon.

AutoFac peut être configuré par code ou par fichier XML. La configuration par code est précunisée dans le cas ou l’on connait à l’avance les dépendances à injecter, ce qui est mon cas puisque je ne vais utiliser que Nhibernate.

Voici le code de mon test unitaire AutoFac

[csharp] [Test] public void TestConfiguration() { var builder = new ContainerBuilder(); builder.Register<NHibernateRepository>().As<IRepository>(); var container = builder.Build(); var rep = container.Resolve<IRepository>();

Assert.IsAssignableFrom(typeof(NHibernateRepository),rep); } [/csharp]

Conventions

• Conventions de mise en majuscules : Décrit les différents systèmes de casse et les modalités d'utilisation de chaque système. "La plupart des conventions d'affectation de noms sont liées à la casse des identificateurs. Il est important de noter que le Common Language Runtime (CLR) prend en charge des langages qui respectent ou non la casse. Les conventions de mise en majuscules décrites dans cette rubrique aident les développeurs à comprendre et à utiliser une bibliothèque."
• Conventions générales d'affectation de noms : Décrit les règles générales permettant de sélectionner des noms clairs et lisibles. "Les conventions générales d'affectation de noms expliquent comment choisir les noms les plus appropriés pour les éléments de vos bibliothèques. Ces instructions s'appliquent à tous les identificateurs. Les sections suivantes traitent des noms choisis pour des éléments spécifiques, tels que les espaces de noms ou les propriétés."
• Noms d'assemblys et de DLL : Décrit les conventions d'affectation de noms aux assemblys managés. "Dans la plupart des scénarios, un assembly comprend l'intégralité ou une partie d'une bibliothèque réutilisable et est contenu dans une seule bibliothèque de liens dynamiques (DLL). Un assembly peut être fractionné entre plusieurs DLL mais il s'agit d'un cas très rare qui n'est pas abordé dans cette instruction."
• Noms d'espaces de noms : Décrit les conventions utilisées pour les noms d'espaces de noms et explique comment limiter les conflits entre espaces de noms. "Le nom choisi pour un espace de noms doit indiquer les fonctionnalités offertes par les types de l'espace de noms. Par exemple, l'espace de noms System.Net.Sockets contient des types qui permettent aux développeurs d'utiliser des sockets pour communiquer sur des réseaux."
• Noms de classes, de structures et d'interfaces : Décrit les conventions à respecter ou à éviter lors de l'attribution de noms aux types. "En général, les noms de types doivent être des groupes nominaux dont le nom est l'entité représentée par le type. Par exemple, Button, Stack et File possèdent tous des noms qui identifient l'entité représentée par le type. Choisissez des noms permettant au développeur d'identifier l'entité ; les noms doivent refléter des scénarios d'utilisation."
• Noms de membres de type : Décrit les méthodes conseillées en matière de sélection de noms pour les méthodes, les propriétés, les champs et les événements.
• Noms de paramètres : Décrit les méthodes conseillées pour choisir des noms de paramètres explicites. "Le choix de noms de paramètres appropriés peut étendre considérablement les possibilités d'utilisation de votre bibliothèque. Un nom de paramètre adapté doit spécifier les données ou fonctionnalités affectées par le paramètre."
• Noms de ressources : Décrit les méthodes conseillées pour la sélection des noms de ressources localisables.

Liens

projet codeplex : http://npress.codeplex.com/ Nouveau projet : nPress