WCF SOA 命名约定
我有一个名为 ServiceLayer 的类库，它充当 ASP.NET MVC 应用程序的存储库。该服务层引用了名为 ProfileService 的 WCF 服务，该服务包含在数据库等上执行 CRUD 操作的 Profile 方法。
我现在需要允许移动设备与我的应用程序进行通信，因此我创建了另一个名为 ProfileService 的 WCF 服务。该服务引用 ServiceLayer 类库并调用它来执行 Profile 操作。
现在这很令人困惑，因为我现在有 2 个 ProfileServices。第一个与我的数据库等通信并将其自身暴露给我的服务层。第二个与我的服务层通信并将其自身暴露给移动设备。
在 SOA 环境中命名服务以避免混淆哪种类型的最佳方式是什么？特别是在类型之间映射时。
我可能还想创建另一个服务，作为系统用户的 API。我将该服务 ProfileAPI 命名为什么？我知道每个 ProfileService 都位于其自己的命名空间中，但这对创建 AutoMapperSettings 或执行手动映射时的可读性没有帮助。
因此，如果有人知道在这种环境中命名服务的好方法，我们将不胜感激。
I have an class library called ServiceLayer which acts as a repository for a ASP.NET MVC application This service layer has a references to a WCF Service called ProfileService which contains Profile methods to perform CRUD operations on a database etc.
I now need to allow mobile devices to communicate with my application so I have created another WCF Service called ProfileService. This service has a reference to the ServiceLayer class library and makes calls to it to undertake Profile operations.
Now this is quite confusing as I now have 2 ProfileServices. The first communicating with my database etc and exposing itself to my service layer. The second communicating with my service layer and exposing itself to mobile devices.
What is the best way to name your services in a SOA environment to avoid confusion of which type is which? especially when mapping between types.
I may also want to create another service which acts as an API to users of the system. What would I name this service ProfileAPI?? I know each ProfileService is in its own namespace but this doesnt help with readability when creating AutoMapperSettings or performing manual mapping.
So if anybody out there knows of a good way to name services in this environment it would be much appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您正在寻找 Service Facade
您最终会得到一个 Facade，它只是一个专门的接口融入您真正的服务。您可以根据需要定义不同的服务（移动、用户、数据库）
You are looking for a Service Facade
You would end up with a Facade, which is just a specialized interface into your real service. You would define the different services as needed (mobile, users, database)