The Database


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]

[4] This is optimistic. In a simple application, such as payroll, the use of an OODBMS would have very little impact on the design of the program. As applications become more and more complicated, the amount of impact that the OODBMS has on the application increases. Still, the impact is far less than what an RDBMS would have.

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.

[5] Sometimes, the nature of the database is one of the requirements of the application. RDBMSs provide powerful query and reporting systems that may be listed as application requirements. However, even when such requirements are explicit, the designers should still decouple the application design from the database design. The application design should not have to depend on any particular kind of database.




Agile Principles, Patterns, and Practices in C#
Agile Principles, Patterns, and Practices in C#
ISBN: 0131857258
EAN: 2147483647
Year: 2006
Pages: 272

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net