c# - 作为 WCF 的数据层与应用内数据层

Question

我正在开发一个使用 WCF 作为数据层的应用程序。

我理解那里的某些好处，例如安全性。这种方法还有什么其他好处或障碍？

序列化和反序列化不是成本性能吗？

维护、测试和可维护性如何？

这种方法的其他缺点是什么？

Answer 1

所以你有一个数据层，它是使用 WCF 访问的。首先，这样做的好处是：您可以将数据层移动到您需要的任何地方，而您的应用程序不应该关心它。（只要 dns 正确解析）如果它托管在 IIS 内，那么您可以通过将 SLL 作为服务前面的安全层来获得一些安全性。如果您的服务编写得很好，您可以轻松地将它们放入负载平衡过程中。

不利的一面是，您需要关注如何公开该服务。如果它将数据以 XML 形式传回，那么与使用 JSON 作为序列化数据的方式相比，您将遭受更大的序列化损失。

在事情的中间（无论好坏）你会强迫自己小心（我希望）你如何格式化你的请求。例如，只传递一个键进行删除，而不是整条要删除的记录。（相信我，我见过这样写的系统！！）

您还应该仔细设计您的服务，以便您的 svc 文件包含如下内容：

   public Customer GetCustomer(int customerID)
   {
         return DataLayer.GetCustomer(customerID);
   }

如果其他应用程序已经在您的 WCF 服务器上，您可以通过这种方式轻松地直接使用您的数据层。一个很好的例子是您可能将数据层隔离在内部网络中。被非军事区庇护。您的 Intranet 可能需要访问相同的数据层，以便您可以将 Intranet 应用程序放在该服务器上并直接使用该数据层。或者它们可以在不同的服务器上，但直接使用数据层库。

最后一点……我们在一种情况下遇到了需要。如果您在 DMZ 上实施需要直接访问服务器而不是通过防火墙路由的东西，您可以轻松地创建数据服务的代理。代理只是获取您的服务接口并通过防火墙实现对 DMZ 后面的服务的调用。我们可能花了一天时间来实现这一点。

对于测试：这与您拥有数据层的任何其他地方没有什么不同。您需要进行测试，在测试设置中使用可重复的数据，并在测试完成后进行适当的清理。它也不会因可维护性等而改变。但是，您需要有一种明确的方法来对服务进行版本控制以包含接口更改。但是，同样，无论您的数据服务位于何处，情况都是一样的。

希望这会有所帮助。