|
Advertisement
|
This page contains an archived post to the Java Answers Forum made prior to February 25, 2002.
If you wish to participate in discussions, please visit the new
Artima Forums.
Message:
Database migration
Posted by Jay on January 23, 2002 at 5:14 PM
A few things.
- My proposal is not a factory.
- Chin's snippet is a perfect implementation of Abstract Factory
- Since my proposal is not a factory, it does not have to behave like a factory. And besides, the
system wont mind if we borrowed a few ideas?!
Now lets see, we made a perfect factory. But what did we actually do? We brought database design into Java code! I mean, I dont want to know any database entities. Why should I have a class that represents a table? I'll tell why not:
- When migrating to a different database, the factory assumes that the database design is not changed.
In fact, most of the time, clients already have a database for a long time, with their own design that they fear changing their design to suit your application because there are a million other applications already running with that database. But you have a 30MB of factory assuming your own design. What do you do? Well, call the programmers, sit down, rewrite!
Or worse yet, the application is glued to the factory! You change the factory, the whole application is a mess.
But please bear in mind that this is in case of generic product using specific database. Whereas in the other case, there is a definite signature (interface) what your application needs, just implement it, and the application runs. I ask-you answer scenario. No more no less.
- You do not know where the data comes from. It could be a file, database(I mean like Oracle), a
socket stream. A streamed source already has a protocol, which it acknowledges, like XML. In that case you are not even expected to implement a factory.
Comments?
P.S Good job Chin & Matt.
Replies:
|
