wcf架构 - 如何以灵活的方式设计我的服务合同

Question

我有一些实体，例如：Customers，Orders，Invoices。

对于他们中的每一个，我将 CRUD操作和其他少数几个分组在以下界面中：ISvcCustomerMgmt，ISvcOrderMgmt，ISvcInvoicesMgmt，ISvcPaymentsMgmt

现在我需要创建几个彼此独立的WCF服务契约，其中包括实现一个或多个这样的接口。

1. 一个供内部使用 ISvcInternal: ISvcCustomerMgmt, ISvcOrderMgmt, ISvcInvoicesMgmt //,maybe more in the future
2. 一个用于外部使用（第三方）ISvcExternal: ISvcCustomerMgmt //,maybe more in the future

所以，我的真实服务看起来像这样：1）SvcInternal: ISvcInternal，2）SvcExternal: ISvcExternal。

当我看到SvcInternal实现时，通过大量操作会变得更大。

这种方法足够灵活吗？你是否建议采用另一种方法将它们拆分？随意分享您的想法。

谢谢。

Answer 1

如果我必须实现这一点，我会说我会将所有代码和操作放在工作者管理器或Fascade层中......这将包括所有操作......（真正的编码逻辑）。

我的服务只是瘦客户端，只会将请求传递给Fascade图层.... 这允许我重用大量的代码......并且它还允许我在没有ReImplementation的情况下在多个服务中公开相同的方法.... 但有一点，你为什么不使用不同的绑定来区分内部和外部服务......例如即使您要为两个服务使用WSHttpBinding或BasicHttpBinding，也要为它们创建不同的端点和绑定....

就Code Hirerachy而言，我的想法是使用文件夹hirerachy和命名空间来区分b / w这个... Namespace.Interfaces.Internal，反之亦然......

希望有所帮助。

Answer 2

这可能是一场无休止的争论......您如何选择对服务运营进行分组取决于您。

一种方法是将所有内容放在一个覆盖所有服务中，作为覆盖内部复杂性的外观。但是，正如你所说，这可以迅速增长。

另一种选择是为每个实体类型或每个聚合根提供一个服务。聚合根是具有ID的实体，可以独立于其他实体进行管理。例如：您可能有Invoice实体和InvoiceLine实体;然后Invoice实体是一个聚合根，但InvoiceLine实体不是，因为它没有Invoice就不存在 - 因此，它不是独立的。

另一种方法是按域划分 - 即将服务划分为更小的服务，每个服务都是一致的，独立于其他服务。有时这是可能的，有时则不然。用你的判断。

Answer 3

在我们公司，服务包括3个组件：

1）＆＃34;合同＆＃34;我们命名为[公司]的组装。[项目]。合同。此程序集包含DTO（域）对象，接口定义和用于访问服务的Client类。可以与想要使用您服务的人共享此程序集。

2）＆＃34;业务＆＃34;我们命名为[公司]的组装。[项目]。商业。此程序集公开一个工厂类，该类将接口返回给内部业务工作者类。

3）＆＃34;服务＆＃34;程序集，我们命名为[公司]。[项目]。传统SOAP服务的服务或[公司]。[项目]。如果是REST服务，它就是＆＃34; facade＆＃34;它发布服务的接口并涵盖传输和协议逻辑。

将所有功能放在一个服务中是一个很好的选择，但您很快就会发现某些类自然地属于一起，因此您可能最终会得到许多特定于域的服务。

现在，WCF具有这个伟大的配置概念，但是那些具有现场经验的人会同意这可能非常繁琐且容易出错，尤其是当您的SOA变得更加复杂时（最终会如此）。这总是导致非常复杂的配置，乘以服务将运行的各种环境（开发，测试，登台，生产）。不用说这可能会导致错误。

为了解决这个问题，我们使用broobu框架，允许使用WS-Discovery和动态代理生成为WCF服务提供接近零的配置，此解决方案的唯一缺点是您最好使用AppFabric 1.1的IIS托管服务。这样，您可以使用IIS来配置服务：更安全（因为您不会使用XML配置文件）并且可扩展性更高。