我正在开发一个使用 WCF 作为数据层的应用程序。
我理解那里的某些好处,例如安全性。这种方法还有什么其他好处或障碍?
序列化和反序列化不是成本性能吗?
维护、测试和可维护性如何?
这种方法的其他缺点是什么?
我正在开发一个使用 WCF 作为数据层的应用程序。
我理解那里的某些好处,例如安全性。这种方法还有什么其他好处或障碍?
序列化和反序列化不是成本性能吗?
维护、测试和可维护性如何?
这种方法的其他缺点是什么?
所以你有一个数据层,它是使用 WCF 访问的。首先,这样做的好处是:您可以将数据层移动到您需要的任何地方,而您的应用程序不应该关心它。(只要 dns 正确解析)如果它托管在 IIS 内,那么您可以通过将 SLL 作为服务前面的安全层来获得一些安全性。如果您的服务编写得很好,您可以轻松地将它们放入负载平衡过程中。
不利的一面是,您需要关注如何公开该服务。如果它将数据以 XML 形式传回,那么与使用 JSON 作为序列化数据的方式相比,您将遭受更大的序列化损失。
在事情的中间(无论好坏)你会强迫自己小心(我希望)你如何格式化你的请求。例如,只传递一个键进行删除,而不是整条要删除的记录。(相信我,我见过这样写的系统!!)
您还应该仔细设计您的服务,以便您的 svc 文件包含如下内容:
public Customer GetCustomer(int customerID)
{
return DataLayer.GetCustomer(customerID);
}
如果其他应用程序已经在您的 WCF 服务器上,您可以通过这种方式轻松地直接使用您的数据层。一个很好的例子是您可能将数据层隔离在内部网络中。被非军事区庇护。您的 Intranet 可能需要访问相同的数据层,以便您可以将 Intranet 应用程序放在该服务器上并直接使用该数据层。或者它们可以在不同的服务器上,但直接使用数据层库。
最后一点……我们在一种情况下遇到了需要。如果您在 DMZ 上实施需要直接访问服务器而不是通过防火墙路由的东西,您可以轻松地创建数据服务的代理。代理只是获取您的服务接口并通过防火墙实现对 DMZ 后面的服务的调用。我们可能花了一天时间来实现这一点。
对于测试:这与您拥有数据层的任何其他地方没有什么不同。您需要进行测试,在测试设置中使用可重复的数据,并在测试完成后进行适当的清理。它也不会因可维护性等而改变。但是,您需要有一种明确的方法来对服务进行版本控制以包含接口更改。但是,同样,无论您的数据服务位于何处,情况都是一样的。
希望这会有所帮助。