Partie 2 - Vue d'ensemble de l'architecture▲
Continuant notre série, je voudrais présenter une architecture sur laquelle je travaille depuis un certain temps et qui peut être utilisée dans des applications métier Silverlight utilisant le DDD (« Domain Driven Development ») et ayant plusieurs couches.
L'image suivante décrit comment une application peut être composée de multiples modules, tous hébergés dans des régions d'un shell. Ces modules peuvent communiquer les uns avec les autres par le biais de messages bien définis et des contrats définis dans le module de la couche d'infrastructure. En outre, ils extraient et manipulent des objets de données à travers des services WCF qui conviennent pour le DDD (appelés WCF RIA Services). Ces objets de données sont souvent appelés des entités et peuvent représenter votre modèle de domaine et sont pérennisés dans un magasin de données en utilisant des objets d'accès aux données. WCF RIA Services vous fournit des moyens de manipuler vos entités dans le client de la même façon que vous le feriez dans le serveur, lorsqu'il s'agit d'interroger, modifier des données et soumettre des modifications.
Une telle application compte souvent sur l'infrastructure du côté serveur pour l'authentification et l'autorisation, la journalisation et la gestion des erreurs. Du côté client elles comptent sur des frameworks qui aident à réduire, harmoniser et réutiliser du code dans le développement de modules tant pour la logique de présentation que pour les vues de présentation. Certaines couches peuvent avoir des composants qui dépendent de composants d'autres couches.
Dans de tels cas, nous réduisons ces dépendances avec des conteneurs IoC ou des frameworks similaires tels que MEF.
Le développement dans une architecture N-tiers peut être problématique lorsque vous souhaitez réutiliser du code qui doit être spécifié tant du côté serveur que du côté client quand il s'agit de la validation ou autre logique métier. WCF RIA Services comptent sur les métadonnées qui décrivent comment sont définies et validées les entités, et comment elles se comportent les unes avec les autres. Bien que cette technique soit très efficace, il y a des problèmes associés qui ne sont pas remarqués jusqu'à ce que vous les rencontriez, et j'essaierai d'en identifier et d'en résoudre quelques-uns.
Notez la couche de mapping entre les entités de données et les entités de domaine. Cette couche est optionnelle et peut être utile lorsque vous ne souhaitez pas exposer vos entités de données en tant que votre modèle de domaine. Cela aide à réaliser l'ignorance de persistance et vous permet aussi de créer des classes simples et légères pour transporter des données. Pour la simplicité, je ne vais pas utiliser cette couche dans les prochaines parties, donc mes entités de données seront mes entités de domaine.
Conclusion▲
Dans les prochaines parties, je vais construire une application qui respecte ces couches et qui évoluera au fil du temps. Je vais également construire un framework simple visant au développement MVVM afin de démontrer à quel point ce pattern peut être efficace.
