Readability vs benefits of polymorphism

Question

We are dealing with a lot of CRUD operations in our application. Each database table has one or more corresponding SQLContainer instances to perform various types of operations. All of these SQLContainers are stored in one helper class, so that you could perform any type of CRUD operation anywhere from the program (once you have the reference to that helper class).

Now that the scale of the application is growing rapidly, this database helper class has also grown immensely (5+ KLOC). The growth of this helper class was impacted by the fact, that every SQLContainer has a seperate set of methods for performing the same operations, e.g. if you had to commit employeesContainer, you would call commitEmployeesContainer() and so only reading the method name gives a clear idea of the action. (You could call getEmployeesContainer().commit(), but we also perform some additional operations after commiting, like returing the status code of the commit which is almost the same for each container except for few containers)

Now we are considering to add some polymorphism to this helper class and create general purpose methods, e.g. for committing records the commitContainer(getEmployeesContainer()) could be used, but such polymorphism will have no typesafety whatsoever and if some table will have few different containers you could accidentally pass a wrong container.

One of the benefits is that you won't have to add new sets of methods when new SQLContainers will be added, and also modifications to the committing algorithm would be easier to adapt.

Question:
Which approach would ease the maintenance whilst keeping the readability or is there an alternative solution for this type of problem?

Answer 1

The common approach to this sort of thing is to create a class (whose name ends with DAO) with static helper methods to perform CRUD methods pertaining to that particular database table. That static class derives from a common static class with protected methods which assist derived classes.

For instance, org.project.dao.UserDAO.getByUsername("MICHAELJ") would be called so that static class UserDAO can return a UserEntity object based on the username passed. The UserDAO would then call the super protected method get passing all information required in order to construct a query and return an object array (array, for when you're expecting multiple values). UserDAO would take the first one, cast it, and return it to the caller (or return null in the case in which none is found). In this way, you're not violating DRY, and you can perform changes to all reads or just UserDAO simply by modifying the appropriate method.

If you're going to use an instance (say, if you wanted to retain database connection info), that is fine too, but you cannot access it in a global manner like you're doing now. You need to pass it into the classes which require it, meaning you're going to have to modify all the classes which currently use your helper class.

Then, I usually take things a step further and create a User class which takes as its only constructor argument, a UserEntity instance. Throughout my program I would use User for getting and setting information and taking care of niceties and data validation. In this way, if UserEntity ever changed, you would not need to change UserDAO unless it were a key field and you would likely need to do little more than add a getter and setter to User leaving the rest unchanged. The User class would be the only class to directly interface with UserDAO, and so that too is easy to fix when necessary.

While this Façade pattern is optional, I find it makes my program very flexible and easily maintainable, all while keeping its readability. I hope that helps!