Using Other Patterns with Databases

Four other patterns that can be used with databases are EXTENSION OBJECT, VISITOR, DECORATOR, and FACADE.^[2]

^[2] The first three patterns are discussed in Chapter 35. Facade is discussed in Chapter 23.

1. Extension Object: Imagine an extension object that knows how to write the extended object on a database. In order to write such an object, you would ask it for an extension object that matched the Database key, cast it to a DatabaseWriterExtension, and then invoke the write function:

   Product p = /* some function that returns a Product */ ExtensionObject e = p.GetExtension("Database"); if (e != null) {   DatabaseWriterExtension dwe = (DatabaseWriterExtension) e;   e.Write(); }

2. Visitor: Imagine a visitor hierarchy that knows how to write the visited object on a database. You would write an object on the database by creating the appropriate type of visitor and then calling Accept on the object to be written:

   Product p = /* some function that returns a Product */ DatabaseWriterVisitor dwv = new DatabaseWritierVisitor(); p.Accept(dwv);

3. Decorator: There are two ways to use a decorator to implement databases. You can decorate a business object and give it read and write methods, or you can decorate a data object that knows how to read and write itself and give it business rules. The latter approach is not uncommon when using object-oriented databases. The business rules are kept out of the OODB schema and added in with decorators.

4. Facade: This is my favorite starting point; indeed, TABLE DATA GATEWAY is simply a special case of FACADE. On the down side, FACADE does not completely decouple the business rule objects from the database. Figure 34-10 shows the structure. The DatabaseFacade class simply provides methods for reading and writing all the necessary objects. This couples the objects to the DatabaseFacade and vice versa. The objects know about the facade because they are often the ones that call the read and write functions. The facade knows about the objects because it must use their accessors and mutators to implement the read and write functions.

Figure 34-10. Database facade

This coupling can cause problems in larger applications, but in smaller apps or in apps that are just starting to grow, it's a pretty effective technique. If you start using a facade and then later decide to change to one of the other patterns to reduce coupling, the facade is pretty easy to refactor.