Page Comparison

Everyone is aware of a Data Source that is configured in the container pointing to a database that is then used within the application through a simple data source lookup. For the sake of clarity, this data source will be referred to as Container Data Source. So what is this Logical Data Source? Let us take an example.

For this application, there will typically be a database user and a Container Data Source configured against this database user for application access. But within the application, there are at the minimum two logical functionality module requiring its own set of data or query modeling – One is the actual shopping cart functionality while the other is its reporting functionality. Initially, the requirement may be to have everything together and have the complete functionality point to the single user. But over period of time and with bigger volumes, there may be a need to move historical data into a separate database and have reporting point to that database. Now the definition of having reporting point to that database effectively means that the entire data access layer logic also should be aware of and point to the database.

This effectively means that while data access layer just provides the abstraction over a data model, what is needed is a logical abstraction above the data model that splits the functionality by modules that can potentially point to different databases. This level of abstraction is what is called as the Logical Data Source.

So what constitutes a Logical Data Source? It is a combination of the following elements:

...

The Database Access Framework works on the concept of Logical Data Source. Applications that do not see the need for this abstraction can create a single Logical Data Source pointing to their Container Data Source, thereby effectively nullifying the abstraction.

Database Access Framework focuses on separating two aspects:

...