J'ai une application Web qui est organisée en projets de données, de gestion et d'interface utilisateur. Au fur et à mesure que le système évolue, les changements sont déployés en construisant les trois projets et en les déployant dans un seul paquet. Cela a bien fonctionné et a permis l'illusion de «trois niveaux» sans aborder les communications, les problèmes de version de systèmes vraiment distincts. Donc, le long d'une demande de résumés XML de certaines des données et mes pensées se tournent vers un service WCF de fantaisie qui, un jour, pourrait être mon "Web API" (ahh ... l'esprit .. quel petit singe maléfique c'est). Donc, en supposant que cela survit à la « est-ce vraiment la meilleure idée? » Test voici ma question:Recommandations sur la manière de découpler les services (RSS, API REST) de mon interface utilisateur (Webforms) lorsqu'ils partagent un même modèle?
Quelle est la structure que vous avez eu le plus de succès avec quand posé avec deux l'évolution des « clients » au service du contenu de un seul "modèle" évolutif?
Oui, c'est absolument large mais j'espère trouver des expériences individuelles avec des approches spécifiques qui se sont bien passées. Je vais certainement lire ce guide, mais je me méfie d'obtenir des conseils abstraits ou des cas de test choisis à la main. Un peu comme si vous voulez sélectionner un ORM, il y a beaucoup de critiques individuelles disponibles. Quand il s'agit du niveau de la logique métier dans le monde .NET, il semble beaucoup plus difficile de trouver des descriptions d'utilisation du monde réel. J'apprécie cependant les conseils, merci! –