While it is difficult to
By the particular data access technology that they use to get the data
By the database that they use to hold their data
The problem with the two definitions above is that the focus is on a purely technological solution.
A well-designed data access tier should transcend any one particular technology or data store.
Technologies change at a rapid rate; a new technology that appears to be a cutting-edge technology can quickly become obsolete. Development teams who couple their applications too tightly with a particular technology or technology vendor, will find that their applications are not as
A data access tier should allow the business services to
Allow a clean separation of data-persistence logic from the presentation and business logic. For instance, a business component should never be passed a Java ResultSet object or have to capture a SQLException . The entire data access logic should be centralized behind a distinct set of interfaces, which the business logic must use to retrieve or manipulate data.
Decouple the application(s) from any knowledge of the database platform in which the data resides. The objects in the business tier requesting the data need not know that they are accessing a relational database such as Oracle, an object-based database such as Poet, or an XML database such as the Apache
Abstract away the physical details of how data is stored within the database and the relationships that exist between entities in the database. For instance, a business-tier class should never know that the Customer object and the Address object have a one-to-many or many-to-many relationship. These details should be handled by the data access tier and be completely hidden from the developer.
Simplify the application development process by hiding the details associated with getting a database connection, issuing a command, or managing transactions. Data access code can be very complicated even though it looks very easy to write. By
As discussed in Chapter 1, the lack of planning for the data access tier results in the formation of the Data Madness antipattern. This antipattern
The creation of tight dependencies between the applications consuming the data and the structures of the underlying data stores. Every time a change is made to the database structure, the developers have to hunt through the application code, identify any code that references the changed database structures (that is, the tables), and then update the code to reflect the changes. This is
The inability to easily port an application to another database platform because of the dependencies on the vendor-specific database extensions. Often,
The inability to easily change data access technologies without rewriting a significant amount of application code. Many developers mix their data access code (that is, their SQL/JDBC or entity EJB lookups) directly in their application code. This intermixing will cause tight dependencies and increase in the amount of code that needs to be reworked, when you want to use a new data access technology.
The presence of a 2.5 tier architecture. A 2.5 tier architecture is an architecture in which there is a well-defined presentation tier for the application, but the business logic is not clearly separated from the data access logic of the application. This particular symptom is sometimes very obvious.
You will find this symptom, when you start
The presence of Data Madness can be easily found by knowing how the data access tier is designed. If the development team says that it is using JDBC, entity EJBs, SQLJ, Oracle, SQL Server, and so on, it is likely that there has been no real preplanning for the data access tier.