Cet article fait partie d'une série d'articles sur comment architecturer une application d'entreprise Silverlight centrée sur les données. Silverlight, lorsqu'elle est combinée avec les patterns les plus populaires aujourd'hui et certaines technologies-clés pour le génie logiciel, peut être une technologie très productive, simple, fiable et efficace pour construire ce genre d'applications, et en même temps, fournir une expérience utilisateur exceptionnelle.

Langage/Outil/Technologie : Silverlight 4.

Commentez ce tutoriel : Commentez

- Titre : Architecturer des applications métier Silverlight

- Auteurs : Manuel Felicio, Deepin Prayag

- Parution : 17 janvier 2013

- Mise à jour : 14 février 2013

- Licence : Copyright © 2013 Manuel Felicio. CDATA[Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 € de dommages et intérêts. Droits de diffusion permanents accordés à Developpez LLC. Cette page est déposée à la SACD.

Sommaire

- Traduction

- Architecturer des applications métier Silverlight - Vue d'ensemble de l'architecture

- Conclusion

- Liens

- Remerciements

Traduction

Cet article est la traduction la plus fidèle possible de l'article original de Manuel Felicio, Architecting Silverlight LOB applications (Part 2) - Architecture overview.

Architecturer des applications métier Silverlight - 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 module 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 ils se comportent les uns 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 prochains articles, donc mes entités de données seront mes entités de domaine.

Conclusion

Dans les prochains articles, 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.

Liens

Pour terminer, je tenais à dire que tout le code est disponible sur http://code.google.com/p/mfelicio-wordpress sous trunk/2010/SL-MVVM-RIA.

Remerciements

Je tiens ici à remercier Manuel Felicio de m'avoir autorisé à traduire son article.
Je remercie tomlev pour sa relecture technique et ses propositions.
Je remercie également ClaudeLELOUP pour sa relecture orthographique et ses propositions.

Architecturer des applications métier Silverlight

Partie 2 - Vue d'ensemble de l'architecture

Auteurs

| Manuel Felicio | Deepin Prayag |