.net 包装或不包装：包装服务外观中的数据访问

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

---

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

这实际上取决于数据服务的使用方式。如果只有少数几个应用程序，这不是什么大问题，但是如果您有许多应用程序，并且在数据方面有很多更改，那么发布更新版本并确保不破坏现有应用程序可能会有问题

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

---

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

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