WCF 体系结构 - 如何以灵活的方式设计我的服务协定

本文关键字：方式 我的 服务 体系结构 WCF | 更新日期: 2023-09-27 17:56:47

我有一些实体，如：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实现时，它会随着大量操作而变得更大。

这种方法是否足够灵活？您是否建议以某种方式将它们分开的另一种方法？随时分享您的想法。

谢谢。

WCF 体系结构 - 如何以灵活的方式设计我的服务协定

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

我的服务将只是一个瘦客户端，只会将请求传递给 Fascade 层。这允许我重用大量代码...它还允许我在多个服务中公开相同的方法，而无需重新实现......有一点，但你为什么不使用区分黑白你的内部和外部服务与不同的绑定......例如，即使您打算对这两种服务使用 WSHttpBinding 或 BasicHttpBinding，也会为它们创建不同的端点和绑定。

就Code Hirerachy

而言，我的想法是使用文件夹Hirerachy和命名空间来区分黑白...例如命名空间.接口.内部，反之亦然...

希望有帮助。

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

一种方法是将所有内容放在一个单一的、覆盖一切的服务中，该服务充当覆盖内部复杂性的门面。但是，正如你所说，这可以快速增长。

另一种选择是每个实体类型或每个聚合根都有一个服务。聚合根是具有 ID 且可独立于其他实体管理的实体。例如：您可能有一个发票实体和一个发票行实体;则发票实体是聚合根，但发票行实体不是，因为没有发票就无法存在 - 因此，它不是独立的。

另一种方法是按域划分 - 也就是说，将服务划分为较小的服务，每个服务都是一致的并且独立于其他服务。有时这是可能的，有时不是。运用你的判断力。

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

1）我们命名为[公司]的"合同"组件。[项目]。合同。此程序集包含 DTO（域）对象、接口定义和用于访问服务的客户端类。此程序集可以与想要使用您的服务的用户共享。

2）我们命名为[公司]的"业务"组件。[项目]。商。此程序集公开一个工厂类，该工厂类将接口返回到内部业务辅助角色类。

3）"服务"组件，我们将其命名为[公司]。[项目]。传统 SOAP 服务或 [公司] 的服务。[项目]。REST 在 REST 服务的情况下，它是发布服务接口并涵盖传输和协议逻辑的"门面"。

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

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

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

相关文章：