ORM – architecture of business object / database access layer

For various reasons, we are writing a new business object / data repository One of the requirements of this layer is to separate the logic of business rules from the actual data storage layer

There can be multiple data storage layers that implement access to the same object – for example, the primary "database" data storage source that implements most objects, and another "LDAP" source that implements user objects In this case, the user can choose from the LDAP source, which may have slightly different functions (for example, the user object cannot be saved / updated), but whether the application uses it in the same way Another type of data store might be a web service or an external database

We have two main ways to achieve this, and my colleagues and I are inconsistent on the basic level, which is correct I'd like to make a suggestion on which one works best I will try to keep the description of everyone as neutral as possible, because I am looking for some objective views here

>Business objects are base classes, and data storage objects inherit business objects Client code handles data storage objects

In this case, the common business rule is inherited by each data storage object, and it is the data storage object directly used by the client code

This implies that the client code determines which data storage method to use for a given object because it must explicitly declare an instance to an object of that type The client code needs to know the connection information of each data storage type it is using

If the data storage layer implements different functions for a given object, the client code knows it explicitly at compile time because the object looks different If you change the data storage method, you must update the client code. > Business objects encapsulate data storage objects

In this case, the business object is used directly by the client application The client application passes the basic connection information to the business layer The decision about which data storage method to use for a given object is made by the business object code The connection information will be a large piece of data obtained from the configuration file (the client application does not really know / care about its details). It can be a single connection string of the database or multiple connection strings of various data storage types Additional data store connection types can also be read from another location – for example, a configuration table in a database that specifies the URLs of various web services

The advantage here is that if you add a new data storage method to an existing object, you can set the configuration settings at run time to determine which method to use, and it is completely transparent to the client application If the data storage method of a given object changes, there is no need to modify the client application. > The business object is the base class, and the data source object inherits from the business object The client code mainly deals with base classes

This is similar to the first method, but the client code declares the variables of the basic business object type, and the load() / create() / etc static method on the business object returns the corresponding data source type object

The architecture of this solution is similar to the first method, but the main difference is that deciding which data storage object to use for a given business object is determined by the business layer rather than the client code

I know that the existing ORM libraries already provide some of these functions, but please discount temporarily (it is possible to implement the data storage layer with one of these ORM libraries) – please note that I deliberately don't tell you what language is used here, except that it is strongly typed

I'm looking for some general advice on which method is better to use (or make other suggestions at will), and why

Solution

I can suggest another alternative that may be better decoupled: business objects use data objects, and data objects implement storage objects This should keep the business rules in the business object, but not depend on the storage source or format, while allowing the data object to support any required operations, including dynamic changes to the storage object (for example, for online / offline operations)

This belongs to the second category above (business objects encapsulate data storage objects), but more clearly separates data semantics from storage mechanisms