I am adapting the "Dine With Me" application to eventually become a full-fledged web-application. One of the issues I am facing is where to store the database information, in the current model the data is hardcoded in the Database class. I have not yet decided how I will solve this, and this blog is in part to help me think about the problem, write down my thoughts and possible solutions.
The core of the application has a facade (DineWithMeFacade), which provides a single-point-of-access, from which all other actions can be executed on the program. Pretty standard facade-pattern and nothing much interesting going on, the Swing-desktop application uses this to add friends, retrieve recipes, login, encrypt and encode information, just as you would expect. However, when developing for android, I extended the DineWithMeFacade to add android-specific features, revealing some of the caching-system methods. In addition, the "AndroidDineWithMeFacade" is singleton. This made passing data between activities easier, as well as avoid creating a new instance of the facade for every activities. (Activities don't have a very long lifetime in the app).
During this, the data was still hardcoded in the core, the Android application simply used an external jar to talk to the core. I never like to choose the "singleton" way to solve a problem, though I believe sometimes it is the right choice occasionally. Now I'm making a web-app I thought of refactoring the DineWithMe Core a little, having stopped working on the project for a month or two gave me some new insight in things I could have done better. (Honestly, putting down your code and not looking at it for a while, then picking it up, is a great way to see how easy your code is to understand!)
Stacking the preliminary building blocks of the web-app gave me a reason to change the core. When building a web-app, I keep my project's properties in the web.xml file and thus would like to store all the database information there. After thinking about this for a while, I realised it's probably a good idea to use a database.properties file in the Swing application, as to avoid having hardcoded passwords scattered throughout the application. This doesn't come as a shock, but it is something I didn't consider when coding hours on end to reach the deadline for the mobile application project.
The key problem is 'Where to set the database parameters'. The facade exposes the setters of the database class, so any class with access to the facade can change this. So far, there is no problem to be found. The android and desktop applications can both use a properties file to read out the data, and pass it to the facade. Meanwhile, the web-app's Servlet can read the data from web.xml and pass it on through the facade, right?
This would work for the android application, but not for the desktop application. The reason? Well if the DWMAndroidFacade extends the normal Facade, but is a singleton. Thus, I could tell the facade to set the parameters for every service and finito, the work is done!
Now I am left wondering, what I should do. I can have the desktop application and web-app extend the normal facade into a "SwingFacade" and "WebFacade", which are singletons. Now the problem is gone but I'm left with more singletons (though only one singleton in the each project).
After doing a quick search through the swing application, for "new DineWithMeFacade()" the results hinted at a rather small refactor. (Well, that's relative, but it's a rather large project!)
After writing this post I'm quite convinced that going the singleton-desktopfacade/webfacade way might be the right way. Singletons pose quite the conundrum, but for a facade I think even the GoF might agree it's acceptable! 🙂