Introduction Without having to necessarily mess up things with some concepts inherent to theory, we might generally conceive database interfaces as a logical representation coded within a class of a database table, where each table field is represented as a class data member. By following this generic rule on a given database table, we're able to build programmatically a class that contains all of the core DML statements required to manipulate table rows, using the methods provided by the class, in this way acting as single access points to the table data. Stepping back to the first article, I've shown a "DBIGenerator" class that quickly creates DB interface classes, spawning the corresponding objects to provide access to a given database table. As you probably remember, this class doesn't scale well in real applications, since it works with a hard-coded database table and fields, thereby limiting significantly its flexibility and portability. In order to solve these relevant issues, this second part will be the starting point for defining a revamped version of the "DBIGenerator" class, which, as we'll see in short order, will be powerful enough to be implemented successfully in the creation of DB interfaces. Confronted with this scenario, it's time to put our coding abilities to the test. Let's go!
blog comments powered by Disqus |