Given these basic principles of separation of data source specifics from the rest of the application, what then are the elements that properly belong in a Data Access object? Keep in mind as we ask this question that a Data Access object is not an ABL construct or anything else with a specific meaning or structure. It is a concept that can be useful to you to think about as you architect your application. We capitalize the term only to identify it as an implementation of a part of the Reference Architecture.
The sample procedures from earlier chapters are a reasonable starting point to identify the proper elements to include in a Data Access object. In later documents we will extend these basic elements with a more detailed API to provide a template with additional standard behavior. In general you can think of a Data Access object as being paired with a Business Entity object that manages the actual ProDataSet instance data for the rest of the application and applies validation and other business logic. This mapping might not be one-to-one, however. For various reasons you might have multiple Business Entities that use the same data sources and therefore the same Data Access object.
There is also no reason why a Data Access object or any other "object" in your application must be thought of as a single ABL procedure. A base procedure can extend its behavior through the use of super procedures or other forms of procedure library. Or a single procedure could manage multiple Data Access objects, if that is appropriate to your situation. The important thing is how you think about organizing your definitions and the code to manage them, and how this fits in with the rest of your application.
So given these points, let us look at some of the elements of a typical Data Access object.
