I'm working with a swing application that does not connect to the internet. It does connect to a database. Before it can do that, it needs to read the IP address of the database from an XML config file that is resident on the local machine. If the app is ported to another computer, the IP could change which is why it's in the config. (that's out of my control). I need a class to hold the IP address so the app can connect to the database. So when the app starts, it reads the config.xml, connects to the database and performs queries. I'd also like to add some more values to the properties of this configuration class after some more queries have been run and results returned. For instance, if I were building a volkswagon, the number of seats, and engine size would be different than if I were building a Ferrari. These results would be returned from the queries. If I create a static instance variable and get an instance of the class, all the information I need would be there or I could add new information as more queries and results are returned. I'd like to avoid using setters but since the class holds a lot of information, the constructor would be ugly with all of the parameters necessary. Does this sound like a candidate for a builder pattern? My understanding is that a factory pattern would create the same type of object every time and I might not need all of the properties. I need the properties available though in case I want to build a Ferrari instead of a Volkswagon. As the user makes choices, I want to add to this class and use its properties to drive other area's of the app without having to return to the database all the time.
I wouldn't create a "configuration" class that holds both the application's runtime configration options and data related to the domain. Typically you could use the Properties mechanism for the former, which can read key / value pairs from a "plain" text file or an simple XML structure. If that's not flexible enough you could always implement your own configuration mechanism based on an XML file, but I'd have a look at the Properties API first.
As for the "domain configuration options", for lack of a better description, I'd be very careful on how to proceed. At first glance caching domain data retrieved from a database, which is what we're talking about, seems like a good idea that's easy to implement, but it can get complicated fast. Here, again, you may be better off using a pre-existing solution. There are serveral caching solutions that you could look at, like EHCache, but you'd still have to tie such a solution to your database access code. At the risk of sounding like a broken record, there are already frameworks that can do this for you. An OR (Object-Relational) mapper like Hibernate or EclipseLink can make use of first and second level caching strategies to minimize database access, and they make working with a database a lot less of a hassle. Although truthfully these frameworks aren't exectly trivial and can themselves be difficult to master. I would really recommend you take a look at ORM technology though.
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Joined: Oct 24, 2000
Thank you I'll look into ORMs. The current architecture uses all stored procs and I built the front end to retrieve the meta data to get the number of columns in the result. I build the model for the JTable using this information by putting the cloumn names in one container and the data in another. This way my JTable stays dynamic based on the results returned. Any table joins or view loo kups are done in the stored proc. Much of this code is inherited and there is already a class for reading XML so I just reused it as well as editing the existing XML file that had it's own xsd schema file. A lot of this code was written in 2003 so I'm trying to bring it up to date. (it used flat files) A lot has changed since then. There aren't any frameworks used either and I'm not sure I want to retrofit something like Spring into this. Originally I didn't think there would be any problem holding the initial database IP with things like title or backgroundImage. They aren't supposed to change over the life of the app. But I think separating them does make sense.
Thanks for your advice.