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

问题描述

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

有可能有实现访问同一个对象的多个数据存储层 - 例如，实现大部分对象主要数据库的数据存储源，以及实现用户对象另一个LDAP来源。在这种情况下，用户可以任选地稍微不同的功能（例如，无法保存/更新用户对象）来从LDAP源，也许，但是否则就由应用程序使用的方法相同。另一种数据存储类型可能是一个网络服务，或外部数据库

有，我们正在研究实施这一主要有两种方式，我和一个同事不同意的基本水平，这是正确的。我想一些建议哪一个是最好的使用。我会尽力让每一个尽可能中性的描述我的，因为我在寻找一些客观的观点在这里。

• 业务对象是基类，以及数据存储对象继承的业务对象。客户端code涉及数据存储对象。

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

  这有一个客户端code确定要使用的数据存储方法给定对象，因为它有明确声明实例该类型对象的含义。客户端code需要明确地知道它正在使用的每个数据存储类型的连接信息。

  如果数据存储层给定对象实现不同的功能，客户端code明确在编译时知道它因为对象看起来不一样。如果数据存储方法改变时，客户端code的更新。




• 业务对象封装了数据存储的对象。

  在这种情况下，业务对象直接使用客户端应用程序。客户端应用程序沿着底座连接信息，业务层传递。哪些数据存储方法给定对象使用由业务对象code作出决定。连接信息是从配置文件中取出（客户端应用程序并不真正了解它的详细信息/服务）的数据块，这可能是一个数据库，或对各种数据存储类型几件连接字符串一个连接字符串。附加的数据存储的连接类型也可以从另一个点读 - 例如，在指定的URL各种网络服务数据库配置表。

  这里的好处是，如果一个新的数据存储方法被添加到现有的对象，配置设置可在运行时设置，以确定要使用的方法，并且它是完全透明的客户端应用。客户端应用不必如果数据存储方法进行修改给定对象的变化。




• 业务对象是基类，数据源对象从业务对象继承。客户端与$基类主要是C $Ç交易。

  这是类似于第一种方法，但是客户端code声明的基础业务对象类型的变量，和load（）/创建（）/等业务对象的静态方法返回相应数据源类型的对象。

  该解决方案的架构类似于第一种方法，但主要区别是将要使用的数据的存储对象为一个给定的业务对象是由业务层，而不是客户端code作出的决定。

我知道，有些提供此功能，但请打折那些现在已经存在的ORM库（有一个数据存储层与这些ORM库的一个实现的可能性） - 也注意到我故意不告诉你，这里正在使用什么语言，比它是强类型等。

我在找一些一般建议这里哪种方法更好地使用（或随时提出别的东西），以及为什么。

解决方案

也许我建议另一种选择，可能有更好的去耦：业务对象的使用的数据对象和数据对象的实施存储对象。本应该保持在业务对象，但没有存储源或格式上的任何依赖的业务规则，同时允许该数据对象，以支持所需的任何操作，包括动态地改变存储对象（例如，联机/脱机操作）

这属于上述（业务对象封装数据的存储对象），第二类，但是从存储机制更加明确分离数据语义

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.

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.

  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.

  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.

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屋！