有一段时间了，我的团队和我一直在Web服务外观（使用WCF）中包装数据访问层并从业务逻辑层调用它。同时，我们可以简单地使用存储库模式，其中业务逻辑层通过接口在本地消耗数据访问层，并且在任何时间点，我们都可以切换它以使其更改为服务（如果需要）。
问题是：什么时候将数据访问层包装在服务外观中，什么时候不是？现在，似乎主要优势是其他应用程序可以使用该服务，但如果它们是用.NET编写的内部应用程序，那么它们只能使用.NET程序集。将DAL包含在我不知道的服务中还有其他优点吗？
答案 0 :(得分：2)
这实际上取决于数据服务的使用方式和方式。如果只有少数几个应用程序并不是太大的交易，但如果你有许多应用程序和数据方面的很多变化，那么推出更新的版本并确保你不会破坏可能会有问题现有的申请。
使用WCF，您可以对有助于降低风险的服务进行版本控制。所以实际上很多都取决于消费者的数量，消费者的位置（内部/外部）和更新频率。
这至少是我在评估时使用的。