This chapter is from the book
This chapter is from the book
This chapter is from the book
Consider these strategies when designing a data accessor abstraction:
-
Define versatile logical operations— Keep in mind that while a data accessor abstraction hides many data access details from application code, the logical operations that it defines must not unnecessarily limit it. A truly useful data accessor abstraction exposes simple, common database operations, but also allows versatility. If the abstraction does not provide all the logical database operations that applications require, then applications need to use the operations that it does define in unexpected or inefficient combinations. This can lead to more convoluted code than if it handles data access directly.
For example, the data accessor abstraction defined in the “Sample Code” section allows the client to designate a selection row when it issues a read operation. A selection row is roughly analogous to a partial or full primary key value. This feature works fine for the sample client application, but suppose another application needed to read a range of employee identifiers. The abstraction does not expose any support for this type of query, so the application would need to read all records and explicitly filter them. In this case, the data accessor abstraction's semantics have caused the application code to be less efficient and more complex.
One strategy for avoiding this scenario is to research application use cases before designing a data accessor abstraction. Writing prototype or hypothetical application code helps you understand what features application developers need and what semantics keep their code clean.
On the other hand, be wary of designing data accessor abstractions too heavily. Adding operations for speculated scenarios may impose a significant development burden and unnecessary complexity on data accessor implementations.
-
Incorporate enhancement and optimization points— A common development tradeoff is to remove features to meet schedule. While architects and developers can plan full-featured, highly scalable applications, they may not be successful if they take years to develop. The Data Accessor pattern enables you to design applications so that you can readily incorporate additional database features and optimizations in subsequent product releases. Even if you do not have enough development resources to incorporate all of an application's desired data access features, you should consider them and determine where and how you will implement them.
A common example involves database platform support. In the first product release, you can deliver a data accessor implementation that supports a single database product using SQL access. If you hide all platform and SQL details within the data accessor implementation, you can add other platforms and database support in later releases without requiring changes to application code.
You can also approach optimizations such as connection pools with a similar strategy. Hiding connection management within a data accessor implementation enables you to conveniently integrate optimizations like these in a single component, again affecting the entire system's performance characteristics without requiring any application code to change.
-
Guard against inefficient application usage— It is common for application code to employ physical database access code inefficiently. This can have significant negative effects on overall system performance. One example is an application that prepares the same statement multiple times. This application's data access code is likely to be measurably slower than the code of an application that reuses statement handles where possible. However, recycling statement handles adds complexity to application code, making them good candidates for encapsulation within a data accessor implementation.
Design your data accessor abstraction so that it is impossible or improbable that application usage will have a significant effect on performance or storage overhead. For example, if you expose the notion of a database connection, make it a logical connection that does not directly incur physical database connection overhead. This way, if an application opens and closes logical connections repeatedly, it will not affect overall system resource overhead.
The data accessor abstraction offers a point where you can bridge the gap between a robust, application-friendly interface and a highly optimized, full-featured implementation.
To completely insulate applications from changes to a particular data accessor implementation, you should minimize all direct references to it. Instead, write application code exclusively in terms of the data accessor abstraction.
However, you need to instantiate data accessor implementation objects at some point. These are three alternatives for centralizing this instantiation so that it is easier to alter in the future:
-
Singleton data accessor implementation— Define a global, singleton instance of a data accessor implementation that any application code can access. The singleton instance initializes itself only once and isolates its initialization details.
-
Initialization and parameter passing— You can instantiate a single data accessor implementation object in your application's initialization code and pass it to any other application code that needs it. This strategy isolates initialization code to a single component, but it requires that many of the application classes' constructors and operations define an extra parameter.
-
Data accessor factory— You can define a globally accessible factory class to instantiate new data accessor implementation instances. You still encapsulate the data accessor initialization within a single module, the factory returns new data accessor implementation instances whenever an application requests them.