Architecturer des applications métier Silverlight

Cette partie est une introduction à la série d'articles que je vais faire sur comment architecturer une application d'entreprise Silverlight centrée sur les données. Alors que Silverlight est une plateforme puissante pour créer d'excellentes expériences utilisateurs interactives pour le Web, le Bureau (et maintenant) le Mobile, elle est aussi le meilleur atout de Microsoft pour créer une technologie multiplateforme et multinavigateur.

Beaucoup de gens voient juste Silverlight comme un autre rival d'Adobe Flash à cause des aspects applications Internet riches que proposent les deux technologies et la solide prise en charge multimédia dont dispose Silverlight. En dépit de cela, nous pouvons tirer nettement plus de bénéfices de Silverlight si on la perçoit en tant que bonne technologie pour l'industrie du logiciel dans les technologies de l'information. Les projets informatiques sont entièrement axés sur la manipulation, la visualisation et la compréhension des données.

Silverlight, qui est un sous-ensemble de WPF (excellente pour traiter des données à travers la liaison de données) et toujours une application .NET, 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.

Dans cette série d'articles je vais essayer d'aborder les aspects importants lorsque vous architecturez une application qui peut démarrer petite, qui est prévue pour durer des années et au fil du temps évoluer en une plus grosse application en raison de nouvelles exigences et être développée par plusieurs équipes sans qu'il en résulte un gros chantier de code auquel personne ne souhaite toucher.

De telles applications sont souvent construites en utilisant les principes suivants.

• Séparation d'aspects

Le principe le plus important. Possibilité de diviser pour régner par la création de couches dans votre application qui sont destinées à faire face à un problème, une tâche ou une fonctionnalité, réduisant ainsi la complexité. Le reste de ces principes sont tous basés sur celui-ci.

• Couplage faible

Possibilité de créer plusieurs composants qui peuvent œuvrer ensemble mais ne dépendent pas les uns des autres.

• Flexibilité

Capacité à répondre aux changements futurs, soit en changeant complètement la technologie sous-jacente ou les besoins métier.

• Extensibilité

Possibilité de créer de nouvelles fonctionnalités par l'extension ou la réutilisation de celles existantes.

• Modularité

Possibilité de créer des secteurs d'activités indépendants bien définis (cohésifs) dans votre application qui peuvent être amenés à évoluer séparément, à s'intégrer les uns aux autres et même être déployés séparément.

• Testabilité

Capacité à éviter/prévenir les bogues inattendus par des modifications ou de nouvelles fonctionnalités que vous effectuez, en testant la logique, le comportement ou les dépendances de votre application.

• Maintenabilité

Capacité à trouver rapidement le code que vous devez modifier, de le comprendre et de le modifier, même si celui qui l'a écrit en premier lieu n'est plus là (ce qui arrive fréquemment).

• Réutilisabilité

Possibilité de réduire le code en créant des composants qui seront réutilisés par d'autres composants nécessitant une fonctionnalité spécifique.

• Indépendance de l'interface utilisateur

Possibilité de changer de contrôles de présentation sans casser ni votre logique de présentation, ni la logique applicative.

• Localisation

Possibilité de cibler plusieurs langues, augmentant ainsi la diversité de votre clientèle.

Je pense à démarrer avec une architecture globale, choisir les bonnes technologies, construire une petite application dessus et ensuite continuer à la « composer ». Je vais commencer par .NET 3.5 et plus tard passer à .NET 4.

Conclusion▲