数据层为WCF与​​应用程序数据层

Question

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

我理解安全等某些好处。这种方法会带来什么其他好处或障碍？

不是序列化和反序列化会降低成本吗？

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

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

Answer 1

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

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

在事物的中间方面（无论好坏）你都会强迫自己小心（我希望）你如何格式化你的请求。例如，仅传递删除键而不是要删除的整个记录​​。 （相信我，我已经看过像这样编写的系统!!）

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

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

这样，如果某个其他应用程序已经位于您的WCF服务器上，您可以轻松地直接利用您的数据层。一个很好的例子就是您可以将数据层隔离在内部网络中。受到DMZ的庇护。您的Intranet可能需要访问相同的数据层，以便您可以将Intranet应用程序放在该服务器上并直接使用数据层。或者它们可以位于不同的服务器上，但可以直接使用数据层库。

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

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

希望这会有所帮助。