J'ai une bibliothèque de classes appelée ServiceLayer qui sert de référentiel pour une application ASP.NET MVC Cette couche de service a des références à un service WCF appelé ProfileService qui contient des méthodes Profile pour effectuer des opérations CRUD sur une base de données etc.Conventions de dénomination WCA SOA
Je dois maintenant autoriser les appareils mobiles à communiquer avec mon application, j'ai donc créé un autre service WCF appelé ProfileService. Ce service fait référence à la bibliothèque de classes ServiceLayer et effectue des appels pour effectuer les opérations de profil.
Maintenant, c'est assez déroutant car j'ai maintenant 2 ProfileServices. Le premier communiquant avec ma base de données etc. et s'exposant à ma couche de service. Le second communique avec ma couche de service et s'expose aux appareils mobiles.
Quelle est la meilleure façon de nommer vos services dans un environnement SOA pour éviter toute confusion quant au type? en particulier lors de la cartographie entre les types.
Je peux également créer un autre service qui agit comme une API pour les utilisateurs du système. Que nommerais-je ce service? Je sais que chaque ProfileService est dans son propre espace de nommage, mais cela n'aide pas à la lisibilité lors de la création d'AutoMapperSettings ou du mappage manuel.
Donc, si quelqu'un connaît un bon moyen de nommer les services dans cet environnement, il serait très apprécié.
Merci Nix, c'est ce que fait ma couche de service. Il agit comme une façade dans l'application. Cependant, comme il fait référence au ProfileService, tous les DataMembers du service, c'est-à-dire les objets UserRequest/UserResponse, sont visibles dans mon MobileService ProfileService où j'utilise également la conception Request/Response. modèle pour mon service et ont également des objets UserRequest/UserResponse. – Cragly
Votre couche de service accède à un ProfileService? cela ne semble pas juste? Cela devrait être le contraire? Une vraie façade devrait parler en termes communs? Ainsi, toutes les façades tireraient parti de la couche de service existante et serviraient simplement de traduction à partir de la couche de service -> client. – Nix
Ouais ma couche de service fait des appels à travers Wcf en interne en utilisant net.tcp. J'ai besoin que cela soit flexible car DB est sur un autre serveur Tout le reste fait référence à la couche de service (ou une représentation de celle-ci à l'exécution en utilisant IoC). Mon service de périphérique mobile utilise ensuite la couche de service pour ses appels dans le système. – Cragly