Now that most of the application has been analyzed, designed, and implemented, we can consider the role of the database. The class PayrollDatabase clearly encapsulates something involving persistence. The objects contained within the PayrollDatabase must live longer than any particular run of the application. How should this be implemented? Clearly, the transient mechanism used by the test cases is not sufficient for the real system. We have several options. We could implement PayrollDatabase by using an object-oriented database management system (OODBMS). This would allow the objects to reside within the permanent storage of the database. As designers, we would have little more work to do, since the OODBMS would not add much new to our design. One of the great benefits of OODBMS products is that they have little or no impact on the object model of the applications. As far as the design is concerned, the database barely exists.[4]
Another option would be to use simple flat text files to record the data. On initialization, the PayrollDatabase object could read that file and build the necessary objects in memory. At the end of the program, the PayrollDatabase object could write a new version of the text file. Certainly, this option would not suffice for a company with hundreds of thousands of employees or one that wanted real-time concurrent access to its payroll database. However, it might suffice for a smaller company, and it could certainly be used as a mechanism for testing the rest of the application classes without investing in a big database system. Still another option would be to incorporate a relational database management system (RDBMS) into the PayrollDatabase object. The implementation of the PayrollDatabase object would then make the appropriate queries to the RDMBS to temporarily create the necessary objects in memory. The point is that any of these mechanisms would work. Our application has been designed in such a way that it does not know or care what the underlying implementation of the database is. As far as the application is concerned, the database is simply mechanisms for managing storage. Databases should usually not be considered as a major factor of the design and implementation. As we have shown here, they can be left for last and handled as a detail.[5] By doing so, we leave open a number of interesting options for implementing the needed persistence and creating mechanisms to test the rest of the application. We also do not tie ourselves to any particular database technology or product. We have the freedom to choose the database we need, based on the rest of the design, and we maintain the freedom to change or replace that database product in the future as needed.
|