我们的应用程序为另一个系统提供了一个用户界面，其数据模式不在我们的控制范围内。我们的应用程序使用 CSLA 创建业务对象，以允许在第三方系统中编辑数据。然而，随着第三方数据模式的发展，我们必须随之发展。但是，在任何给定时间，我们的客户都可以拥有具有不同数据模式的任何版本的第三方系统。因此，我们的应用程序需要能够适应客户碰巧拥有的任何受支持的模式版本。
我们研究了使用策略模式来解决这个问题的可能性。本质上有一个支持最低版本的数据模式的基类，然后有派生类来支持每个后续版本。反过来，我们将有一个工厂返回与当前版本的数据模式相对应的类。然而，我们担心这可能会导致长而困惑的继承链。有没有更好的方法来解决这个问题？可能用组合而不是继承？
我发现这篇文章概述了处理此问题的可能方法 http://securesoftwaredev.com/2009/05/31/supporting-multiple-versions-of-a-data-model/
我不确定这种方法是否适合我们，但想在实现任何内容之前获得一些其他想法。
最佳答案
CSLA .NET 可以轻松地将数据访问逻辑 (DAL) 与应用程序的其余部分分开。
因为您应该使用 CSLA 创建映射到问题域而不是数据库形状的业务对象，所以您的 DAL 应该关注访问数据库以及根据需要将数据映射到业务对象。
如果您有两个不同的数据库架构，那么您可能会有两个 DAL 实现，它们都访问数据库并将数据映射到完全相同的业务类型。
Using CSLA 4: Data Access电子书相当广泛地涵盖了这一点，ProjectTracker 示例(版本 4.0 及更高版本)也使用了抽象 DAL 来演示该概念。
关于design-patterns - 支持数据模式的多个版本，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14583758/