Comment rendre le cadre et les applications dépendantes faiblement couplés?

Question

J'ai un cas spécifique et je veux savoir le best practice façon de le gérer. Je crée un framework .NET spécifique (application web). Cette application web agit comme une plate-forme ou un framework pour de nombreuses autres applications web grâce à la méthodologie suivante:

Nous créons nos applications web dépendantes (classes pour l'entreprise du projet, rapports rdlc) dans des solutions séparées puis les construisons.

Ensuite, nous ajoutons des références à la DLL créée dans le framework.

Et créer un ensemble de contrôles utilisateur (un pour chaque application Web dépendante) et les mettre dans un dossier dans le cadre lui-même.

Cela fonctionne très bien, mais toute modification apportée à un contrôle utilisateur spécifique ou à toute modification de l'une des applications Web dépendantes. Nous devons à nouveau ajouter les références et publier l'ensemble du framework !!

Ce que je veux faire est de faire ces applications Web différentes et le cadre couplé lâchement. Donc, je pourrais publier le cadre une et une seule et toutes les modifications apportées aux contrôles utilisateur ou les différentes applications Web juste publier la partie mise à jour plutôt que l'ensemble du cadre.

Comment refactoriser mon code afin que je puisse le faire?

La chose la plus importante est:

Jamais le cadre publier tout si le changement dans l'application dépendante, tout simplement publier la partie mise à jour appartient à cette application.

Answer 1

Si le couplage lâche est ce que vous recherchez, développez votre «framework (application Web)» pour qu'il fonctionne comme un service Web WCF. Vos applications client transmettront des requêtes à vos services Web et recevront des réponses standard sous la forme d'objets prédéfinis.

Si vous suivez cette route, je vous recommande d'implémenter une étape supplémentaire: N'utilisez pas les objets transmis à vos applications client directement dans votre code client. Au lieu de cela, créez des versions de ces objets de service Web locaux pour chaque application cliente et, à la réception de vos objets de réponse de service Web, associez-les à leurs homologues locaux. J'ai tendance à implémenter ceci avec un projet de façade dans ma solution client. La façade gère tous les appels à mes différents services Web, et fait le mappage entre les objets client et service automatiquement avec chaque appel. C'est très pratique. La raison en est que le jour où vous décidez de modifier les objets que votre service Web sert, il vous suffit de modifier les algorithmes de mappage dans vos applications client ... le code interne de chaque solution client reste inchangé. Ne sous-estimez pas combien de travail cela peut vous sauver!

Le développement de services Web WCF est un sujet assez vaste. Si vous êtes intéressé, un livre que je recommande est Programming WCF Services. Il offre une très bonne introduction au développement de WCF pour ceux qui viennent d'un arrière-plan .NET.

Answer 2

Je suis totalement d'accord avec levib, mais j'ai aussi quelques conseils:

1. Comme alternative à WCF (avec ses besoins de configuration fou), je recommanderais ServiceStack.Comme WCF, il vous permet de recevoir des requêtes et de renvoyer des réponses sous la forme d'objets prédéfinis, mais sans génération de code ni configuration minimale. Il prend en charge tous les types de formats de réponse, tels que JSON, XML, JSV et CSV. Cela le rend beaucoup plus facile à consommer par exemple. JavaScript et même des applications mobiles. Il a même des binaires pour MonoTouch et Mono pour Android! Il est également hautement testable et flamboyant rapidement!

2. Un excellent outil pour la partie de mappage de votre code est AutoMapper, il vous permet de configurer tous vos mappages dans un seul endroit et mapper d'un type d'objet à l'autre en appelant une méthode simple.

Découvrez-les! :)

Answer 3

Des décennies d'expérience disent: évitez le cadre et vous n'aurez pas de problème à résoudre.

Les structures évoluent comme le cancer. La route vers l'enfer est pavée de bonnes intentions, et une bonne partie de ces bonnes intentions sont incarnées dans une tumeur colossale d'un cadre tout au nom d'une réutilisation potentielle qui n'arrive jamais vraiment. Ayez de l'expérience et des connaissances en matière d'OO et de design, et vous trouverez des solutions sans fin à votre problème technique, comme les façades et les souvenirs, et vous, mais ce ne sont pas des solutions à votre véritable problème. .

Une autre chose, si vous utilisez la technologie MS, ne vous embêtez pas avec quoi que ce soit au-delà de ce que .NET offre. Stick avec ce que les dieux MS offrent parce que dès que vous digresser et devenir engagé dans un cadre interne, vos jours sont comptés.