包装或不包装：在服务外观中包装数据访问答案

【问题标题】：To Wrap or Not to Wrap: Wrapping Data Access in a Service Facade包装或不包装：在服务外观中包装数据访问
【发布时间】：2011-02-18 04:51:50
【问题描述】：

一段时间以来，我和我的团队一直在将数据访问层包装在 Web 服务外观（使用 WCF）中，并从业务逻辑层调用它。同时，我们可以简单地使用存储库模式，其中业务逻辑层通过接口在本地使用数据访问层，并且在任何时间点，我们都可以将其切换为访问服务（如果需要）。

问题是：什么时候将数据访问层封装在服务外观中合适，什么时候不合适？目前，主要优势似乎是其他应用程序可以使用该服务，但如果它们是用 .NET 编写的内部应用程序，那么它们可以只使用 .NET 程序集。将 DAL 封装在我不知道的服务中还有其他好处吗？

【问题讨论】：

即使对于内部应用程序，如果您的程序集有很多用户，直接使用 .NET 程序集也可能是要更新的 PITA，但 Web 服务会更加精简。
这是一个很好的问题......与序列化/传输/反序列化相关的费用可能非常昂贵，因此考虑其他模型是有意义的。另一方面，拥有服务外观可以更轻松地丰富和转换数据。此模式的另一个优点是能够集成队列端点以满足即发即弃的存储需求。

【解决方案1】：

这实际上取决于将要使用什么/如何使用数据服务。如果只有几个应用程序，这没什么大不了的，但是如果您有很多应用程序并且在数据方面有很多更改，那么推出更新版本并确保您不会中断可能会出现问题现有的应用程序。

使用 WCF，您可以对有助于降低风险的服务进行版本控制。因此，实际上这在很大程度上取决于消费者的数量、消费者的位置（内部/外部）以及更新频率。

这至少是我在评估时使用的。

【讨论】：