L'interface Web doit-elle être un client pour mon service?

Question

Notre produit a deux interfaces: une interface Web (ASP.NET) et une interface de service (WCF).

Quelle est la bonne façon de les connecter à la logique métier? L'interface Web doit-elle être seulement un client pour le service WCF (voir les schémas ci-dessous)?

a. WebUI et WCF séparés:

User1 -> ASP.NET -/-> Business Layer 
User2 -> WCF ----/ 

b. WebUI est juste un client du service

User1 -> ASP.NET -/-> WCF -> Business Layer 
User2 -----------/ 

Answer 1

Si votre service expose absolument tout ce que votre application Web doit faire, alors pourquoi ne pas l'utiliser !? ... Si ce service est destiné à des clients ou à d'autres services similaires, l'utiliser soi-même est un bon moyen de tester/s'assurer qu'il fait tout ce dont vous avez besoin.

Answer 2

Je voudrais encapsuler la logique métier dans une DLL commune que les deux services utiliseront.

Dans le service (IIS/WCF) poignée seule communication/protocole/sérialisation etc ....

De cette façon, il est plus facile à mettre en œuvre et les performances sont meilleures.

Answer 3

Cela dépend également de l'architecture de votre client. Si vous utilisez quelque chose comme MVC, vous devrez peut-être créer de grandes quantités de ViewModels. Si vos services WCF sont granulaires, il peut être logique que les services retournent des objets DTO fortement typés. Si vous partagez la DLL contenant les contrats de service avec votre client, vous serez en mesure d'utiliser les DTO contenus dans les réponses de service en tant que ViewModels. Vous avez l'avantage de modifier différemment votre application d'interface utilisateur et votre middleware de logique métier en les découplant de cette manière.