This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Martin Fowler's Patterns of Enterprise Application Architecture (P of EAA) has some patterns that can be useful. Maybe you can get some inspiration. Although if is a stand alone process and you don't need to do any special processing or validation, keep it as simple as possible: for each row put whatever comes from the recordset into the cvs file. As much as I like OOAD, sometimes is not required, and patterns shouldn't be applied always...
Though it's very easy to create a .CSV immediately after fetching data from database in DAO. I'd prefer to wrap this data in a Value Object and send it back, then the business class uses some other bean to really create the file. This way I feel I can keep Data Access Layer and Business Layer independent. I'm going to use Singleton Patterns for Business and Data Access classes. Please add something to make it more efficiet.
And if you want efficiency, then the structure of the database or the SQL queries may have the greatest impact on efficiency.
SCJP 1.4, SCWCD 1.3, SCBCD 1.3
Joined: Jan 07, 1999
Originally posted by Naren Chivukula: Though it's very easy to create a .CSV immediately after fetching data from database in DAO. I'd prefer to wrap this data in a Value Object and send it back, then the business class uses some other bean to really create the file. This way I feel I can keep Data Access Layer and Business Layer independent. I'm going to use Singleton Patterns for Business and Data Access classes. Please add something to make it more efficiet.
Are you planning on re-using any of this code for anything else? If not, then all the effort of creating separate layers and stuff is not only a waste of time, it can also get in the way of seeing what the code is doing, which in turn makes any future maintenance harder rather than easier.
Here's an example of a simple batch program to read stuff from a database and write it to a CSV file. This happens to use my Stringtree DatabaseWrapper class, but even using "raw" JDBC it's not a tricky problem.
The bottom line is don't make things more complicated than they need be.
However the additional work of abstracting a reader and writer is only worthwhile if you already know that in addition to a "CsvWriter", you also need an "XmlWriter", "HtmlWriter" etc. The other consideration is that the Reader/Writer setup may be easier to test.
Originally posted by Don Morgan: Sometimes things like this, particularly if they are very small, simple, and/or single use, are easier to do in a little shell script instead of a full blown java program.
I agree, but with small, potentially simple programs unfamiliarity with tools and libraries can have a disproportionate effect. Often going with a familiar language and development environment can work out quicker than trudging into unfamiliar territory.
For example, it would probably take me longer to work out how to get results from a database query into a shell script for processing than it did to knock together the Java example above. But that's because I do that sort of database access from Java pretty much every day.