业务对象/数据库访问层的架构 [英] Architecture for a business objects / database access layer

问题描述

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

For various reasons, we are writing a new business objects/data storage library. One of the requirements of this layer is to separate the logic of the business rules, and the actual data storage layer.

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

It is possible to have multiple data storage layers that implement access to the same object - for example, a main "database" data storage source that implements most objects, and another "ldap" source that implements a User object. In this scenario, User can optionally come from an LDAP source, perhaps with slightly different functionality (eg, not possible to save/update the User object), but otherwise it is used by the application the same way. Another data storage type might be a web service, or an external database.

我们正在考虑通过两种主要方式来实现这一点，我和一位同事在基本层面上存在分歧，这是正确的.我想就哪一个最适合使用提供一些建议.我会尽量保持对每一个的描述中立，因为我在这里寻找一些客观的观点.

There are two main ways we are looking at implementing this, and me and a co-worker disagree on a fundamental level which is correct. I'd like some advice on which one is the best to use. I'll try to keep my descriptions of each as neutral as possible, as I'm looking for some objective view points here.

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

• Business objects are base classes, and data storage objects inherit business objects. Client code deals with data storage objects.

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

In this case, common business rules are inherited by each data storage object, and it is the data storage objects that are directly used by the client code.

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

This has the implication that client code determines which data storage method to use for a given object, because it has to explicitly declare an instance to that type of object. Client code needs to explicitly know connection information for each data storage type it is using.

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

If a data storage layer implements different functionality for a given object, client code explicitly knows about it at compile time because the object looks different. If the data storage method is changed, client code has to be updated.

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

Business objects encapsulate data storage objects.

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

In this case, business objects are directly used by client application. Client application passes along base connection information to business layer. Decision about which data storage method a given object uses is made by business object code. Connection information would be a chunk of data taken from a config file (client app does not really know/care about details of it), which may be a single connection string for a database, or several pieces connection strings for various data storage types. Additional data storage connection types could also be read from another spot - eg, a configuration table in a database that specifies URLs to various web services.

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

The benefit here is that if a new data storage method is added to an existing object, a configuration setting can be set at runtime to determine which method to use, and it is completely transparent to the client applications. Client apps do not need to be modified if data storage method for a given object changes.

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

Business objects are base classes, data source objects inherit from business objects. Client code deals primarily with base classes.

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

This is similar to the first method, but client code declares variables of the base business object types, and Load()/Create()/etc static methods on the business objects return the appropriate data source-typed objects.

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

The architecture of this solution is similar to the first method, but the main difference is the decision about which data storage object to use for a given business object is made by the business layer, not the client code.

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

I know there are already existing ORM libraries that provide some of this functionality, but please discount those for now (there is the possibility that a data storage layer is implemented with one of these ORM libraries) - also note I'm deliberately not telling you what language is being used here, other than that it is strongly typed.

我正在这里寻找一些关于哪种方法更适合使用(或随意提出其他建议)以及原因的一般建议.

I'm looking for some general advice here on which method is better to use (or feel free to suggest something else), and why.

推荐答案

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

might i suggest another alternative, with possibly better decoupling: business objects use data objects, and data objects implement storage objects. This should keep the business rules in the business objects but without any dependence on the storage source or format, while allowing the data objects to support whatever manipulations are required, including changing the storage objects dynamically (e.g. for online/offline manipulation)

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

this falls into the second category above (business objects encapsulate data storage objects), but separates data semantics from storage mechanisms more clearly

这篇关于业务对象/数据库访问层的架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！