The Repository design pattern extracts the intricacies of data manipulation from the business object layer. As Figure 11-3 illustrates, in the typical client/server application, business rules and data manipulation are written in the client application. Switching to a three-tier architecture removes the business rules and data manipulation from the client and moves them to the business object layer. Consequently, the client code is leaner and simplified to a great extent. Also, via COM technology, the business objects are reusable and accessible to other client applications, which can utilize some or all of the business objects in a unique manner to produce a different implementation of the business process.
Figure 11-3. Evolution diagram of advanced data-based Visual Basic development.
However, the business objects in a three-tier architecture are forced to manipulate data directly, hence moving the complexity out of the client and into the business object layer. Now the business object layer is constrained by the details surrounding the specific data store technology. The Repository design pattern abstracts the data manipulation process into a separate layer, minimizing the complexities and limitations associated with data manipulation in a data store.
Plug-and-play repository implementations for dissimilar data stores without a single code change are a built-in benefit of the Repository design pattern. Different concrete classes that implement the same Repository interface can provide behavior unique to persisting an object's state to its underlying data store.
The Repository design pattern produces a more efficient data manipulation scheme. A repository could, for example, maintain a database connection pool, avoiding the overhead of a one-to-one client connection. A repository could also maintain a cache, avoiding constant data requests to the underlying data store.
Object persistence is optional. By default, a class is not persistable. The programmer must make a conscious (but minimal) effort to make a class persistable, which is fully explained in the "Implementation" section of this chapter.