Dans cette première partie de la série sur l’architecture LOB je vais me concentrer sur certains projets open source dans Microsoft « Patterns & Practices technologies » et d’autres qui sont disponibles et peuvent nous aider à atteindre notre objectif.

Nous avons d’abord PRISM (Composite Application Guidance for WPF et Silverlight). PRISM est composé d’une orientation et d’un ensemble de bibliothèques qui sont conçus pour vous aider à créer plus facilement des modulaire WPF et des application Silverlight. Il a également intégré dans les composants qui vous permettent de profiter de certains des modèles connus comme MVVM, événement agrégateur et l’injection de dépendance. Il existe d’autres, mais je vais me concentrer sur ces trois.

PRISM s’applique aux développement Client. Je pense que la meilleure caractéristique de PRISM est d’offrir la possibilité de spécifier vos modules applicatifs (XAPs dans Silverlight) comme un catalogue et de les charger à la demande. Nous allons explorer cette question en détail dans d’autres parties de cette série lorsque nous créons un catalogue de module pour être utilisé dans l’application.

L’injection de dépendance (un usage spécifique de la notion d’inversion de contrôle) est une technique de choix pour le renforcement des applications faiblement couplés, car il fournit les moyens de gérer les dépendances entre les objets. Il vous aide à construire un code testable, car vous pouvez facilement passer des implémentations concrètes que votre objet en dépend. PRISM est construit en utilisant ce principe de conception et il utilise le conteneur Unity, qui met en Å“uvre la technique de DI (Dependency injection). PRISM permet également d’utiliser d’autres récipients DI, mais je vais me concentrer sur Unity.

Ce modèle peut être appliqué tant dans le développement client et serveur.

Le pattern MVVM est entrain de devenir l’alpha et l’omega dans le developpement d’application WPF et silverlight. Il vous aide à séparer vos couches : la conception de votre couche de présentation et si elle est bien pensé, vous pouvez créer un grand ensemble de code réutilisable et même les réutiliser pour d’autres applications.

Avec MVVM vous pensez essentiellement à votre view comme un ensemble de classes et de propriétés et non comme un ensemble de contrôles d’interface utilisateur (UI).Cela vous permet de passer facilement à votre interface utilisateur tout en conservant la même logique, et en même temps permet la testabilité. De plus, il vous permet de réutiliser un ensemble de la logique UI dans beaucoup de vues avec moins d’effort. Ce modèle est appliqué au développement client.

Le pattern Event Aggregator vous permet de construire votre application avec une Driven Architecture de l’événement où les composants communiquent entre eux de manière découplée. La seule chose que vous devez savoir est l’événement que vous publiez ou vous vous inscrivez et comment réagir face à cet événement. Habituellement les modules ne dépendent pas les uns des autres.

Ensuite, nous allons mettre l’accent sur le développement côté serveur.

la communication Client-server dans Silverlight recommande d’utiliser des services web. Puisque nous sommes dans la création d’applications LOB il est logique d’utiliser les services qui sont bon pour traiter des données. Les services WCF sont recommandé, mais sont-elles idéales? Quel est le coût du maintien d’une couche de service complete qui nous permet d’exposer les opérations CRUD (création, modification, suppression) sur nos données et nous fournit également la capacité de faire d’autes requêtes (comme obtenir des produits par productType) ? Combien de fois avons-nous fait cela? Et combien de fois avons-nous fait cela pour différentes applications? quand est il de la validation des données sur le serveur et le côté client ? quand est il de génération de proxy ? quand est il de la quantité de données envoyées sur le wire juste pour changer une valeur DateTime sur la base de données ?

Nous savons tous que le code généré par Visual Studio est laid comme l’enfer et le maintien du côté client des agent de service complète peut être gênant, parce que vous avez habituellement besoin de garder la synchronisation avec votre contrat de service. Dans Silverlight, il est un peu plus compliqué de partager un ensemble de contrats de service et les données de WPF, en raison d’incompatibilités de type. Aussi nous aimons habituellement les données côté client pour mettre en Å“uvre nos contrats INotifyPropertyChanged et ObservableCollections.

WCF RIA Services vise à résoudre tous ces problèmes et bien d’autres. Les caractéristiques les plus importantes, nous explorerons : la composition des requête, la validation des données, le suivi des modifications, unit of work, entre autres.

Suite : prochain poste

PS : cet article est une adaptation en français d’une suite d’articles par Manuel Felício

Kamel DJELLAL
Chef de projet
EDIS CONSULTING – GROUPE UBISIDE

http://www.ubiside.fr/