问业务对象/数据库访问层的体系结构

EN

出于各种原因，我们正在编写一个新的业务对象/数据存储库。这一层的要求之一是将业务规则的逻辑与实际的数据存储层分离。

有可能有多个数据存储层来实现对同一对象的访问--例如，实现大多数对象的主“数据库”存储源和实现用户对象的另一个"ldap“源。在这种情况下，用户可以选择来自LDAP源，可能具有稍微不同的功能(例如，不可能保存/更新用户对象)，但否则应用程序将以相同的方式使用它。另一种数据存储类型可能是web服务或外部数据库。

我们有两种主要的方式来实现这一点，而我和一位同事在一个正确的基本层面上存在分歧。我想听听关于哪一个最好使用的建议。我将尽量保持我对每一个描述的中性，因为我在这里寻找一些客观的观点。

• 业务对象是基类，数据存储对象继承业务对象。客户端代码处理数据存储对象。

在这种情况下，通用业务规则由每个数据存储对象继承，客户端代码直接使用的是数据存储对象。

这意味着客户端代码决定对给定对象使用哪种数据存储方法，因为它必须将实例显式声明为该类型的对象。客户端代码需要显式地知道它所使用的每种数据存储类型的连接信息。

如果数据存储层为给定对象实现了不同的功能，客户端代码在编译时就会显式地了解它，因为对象看起来不同。如果数据存储方法发生更改，则客户端代码必须是封装数据存储对象的updated.

• Business对象。

在这种情况下，客户端应用程序直接使用业务对象。客户端应用程序将基本连接信息传递到业务层。由业务对象代码决定给定对象使用哪种数据存储方法。连接信息将是从配置文件中获取的数据块(客户端应用程序并不真正了解/关心它的详细信息)，它可能是数据库的单个连接字符串，也可能是用于各种数据存储类型的多个连接字符串。其他数据存储连接类型也可以从另一个位置读取--例如，数据库中指定各种web服务URL的配置表。

这里的好处是，如果向现有对象添加了新的数据存储方法，则可以在运行时设置配置设置，以确定使用哪种方法，并且对客户端应用程序完全透明。如果给定对象的数据存储方法发生变化，则不需要修改客户端应用程序。

• 业务对象是基类，数据源对象继承自业务对象。客户端代码主要处理基类。

这与第一种方法类似，但是客户端代码声明了基本业务对象类型的变量，业务对象上的Load()/Create()/etc静态方法返回适当的数据源类型对象。

该解决方案的体系结构类似于第一种方法，但主要区别在于由业务层而不是客户端代码来决定用于给定业务对象的数据存储对象。

我知道已有的ORM库提供了一些这种功能，但请不要考虑这些库(有可能使用这些ORM库之一实现数据存储层)--还请注意，我故意不告诉您这里使用的是哪种语言，只是它是强类型的。

我在这里寻找一些一般性的建议，关于哪种方法更适合使用(或者随意建议其他方法)，以及为什么。