« App I want: #1 for today | Main | Republican Computer Scandal »
January 19, 2004
App I want: #2 for today
I would like to have a web service or servlet that will connect to a (dynamically specified) database and execute a (dynamic) query. So that I don't need to include my "DB.java" module in every web app I write.
I want the equivalent of a transparent database layer that I can reference from my applications, rather than building it each time.
I have something similar, in that I have a "DB.java" class that I use in most of my web applications with minor changes for each app. But I'd like to have this abstracted... The difference between "Code Reuse: Cut and Paste" and "Code Reuse: Load a module". The first is what usually happens; you have a useful software component, so you copy the file between projects. It's good, in that you only write the original code once. However, if when you find a bug in the code, you have to (and rarely do) go back and patch the older applications / version of the file. So then you have to try to remember which is the latest app, so that you don't pull an older version of the file...
Anyway -- In addtition to the standard DB routines, I also have some interesting utility code related to databases. "ResultSet to CSV", "ResultSet to XML" and while I can't think of any others, I'm sure I have other utilities in one or more projects. The same situation (re bugs) is here, but also there is a similar situation regarding functionality. If I suddenly have this great idea for a new utility function, it doesn't get built into the older apps, and again I have to be careful to use the latest version of the module rather than being able to grab it from any and know it's the latest.
So I just figured out one way I could do this -- to package the DB and Utility code into my own 'core services' jar file. As long as I keep the API consistent, I can just update the AlanCore.jar (for example) independantly, and keep it as its own project. That's probably the easiest way.
Which sort of solves the problem I got into down the line, but I'm not sure whether I'd also want the separate app where my database-access code lives on its own.
The primary problem I had come up with for this "DBServices" application is security, but I could have an API where the requests come loaded with auth info, e.g.:
which is a neat little schema/api.
The results might be:
etc.
Posted by aland at January 19, 2004 3:42 PM
Trackback Pings
TrackBack URL for this entry:
http://www.aland.us/mt/mt-tb.cgi/41
Comments
I mentioned this thought process to a coworker at lunch Tuesday. He said quite clearly, "Just put it into a common jar file." :)
Ok, maybe I oversimplified the discussion with him, but there's really no question that I tend to overthink these decisions. :-)
Next step, refactor. Make sure I know the most current version, and build up a core library of common code.
Posted by: Alan at January 21, 2004 9:37 AM