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

由于各种原因,我们正在编写一个新的业务对象/数据存储库.该层的要求之一是分离业务规则的逻辑和实际的数据存储层.

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

我们有两种主要方式来实现这一点,而我和同事在基本层面上是不一致的,这是正确的.我想就哪一个最好用的建议.我会尽量保持对每个人的描述尽可能保持中立,因为我在这里寻找一些客观的观点.

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

在这种情况下,公共业务规则由每个数据存储对象继承,并且它是客户端代码直接使用的数据存储对象.

这暗示客户端代码确定将哪个数据存储方法用于给定对象,因为它必须显式地向该类型的对象声明实例.客户端代码需要明确知道它正在使用的每种数据存储类型的连接信息.

如果数据存储层为给定对象实现不同的功能,则客户端代码在编译时明确地知道它,因为该对象看起来不同.如果更改了数据存储方法,则必须更新客户端代码.

业务对象封装数据存储对象.

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

这里的好处是,如果将新数据存储方法添加到现有对象,则可以在运行时设置配置设置以确定使用哪种方法,并且它对客户端应用程序完全透明.如果给定对象的数据存储方法发生更改,则无需修改客户端应用程序.

业务对象是基类,数据源对象是从业务对象继承的.客户端代码主要处理基类.

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

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

我知道现有的ORM库已经提供了一些这样的功能,但请暂时折扣(有可能用这些ORM库之一实现了数据存储层) - 另请注意我故意不告诉你这里使用的是什么语言,除了它是强类型的.

我正在寻找一些关于哪种方法更好用(或随意提出其他建议)的一般建议,以及为什么.

我可以建议另一种替代方案,可能更好地解耦:业务对象使用数据对象,数据对象实现存储对象.这应该将业务规则保留在业务对象中,但不依赖于存储源或格式,同时允许数据对象支持所需的任何操作,包括动态更改存储对象(例如,用于在线/离线操作)

这属于上面的第二类(业务对象封装数据存储对象),但更清楚地将数据语义与存储机制分开