DAO pattern?

> hey all, I am currently working on this project and

> require some professional opinions from all of you

> experts! The project is fairly simple, it takes

> various type of input files (xml - objects generated

> using castor; text file with fixed length format;

> excel) and inserts them into their appropriate tables

> using either JDBC or SQLJ.

>

> 1) I want to know if there is a way to not hard coded

> the SQL statement, so I don't need to go back and

> change the code if I added new fields to my

> database?

>

Sorry, part and parcel with the technology. If one changes, you should update the other. Adding field should not be too distruptive. And if you are using a code-gen tool like Middlegen, it should be able to safely pick up new fields. However, changing fields or removing them will nearly always require you to address in your code (assuming the columns were being previously used).

> 2) I am fairly new to this OO stuff, can anyone

> suggests how should I split this project up? Now, I

> have

> input file -> record objects -> database object ->

> DAO

> and it seems like everytime I change my business

> logic, I have to change 80% of my codes!

>

Seems over-architected. Record object and database object should be so similar that they could be the same object, especially if you also have a DAO.

> can anyone helps? please!

- Saish

Saisha at 2007-7-13 11:35:31 >

> yes you are right, record object and database object

> are basically the same thing, but there is a very

> small difference

>

> 1) record object contains all the data directly from

> the input file

In my mind, the situation is simple. You have two DAO's. One reads an input file (remember, data access object does not only mean databases) and the other reads from the database. Presumably, both populate the same model object. :^)

> 2) database object contains only the fields exist in

> the database

>

See above.

> I wonder if they can simply be grouped together...I

> just want to present as many 'layer' as possible so

> that changes to the business logic won't affect the

> database

>

See above. Though, keep in mind the following. Logic changes are fine. Data (or state or instance variable) changes probably require you to also modify database code. Assuming you want to be able to completely restore an object from the database, instance variables and/or database columns need to be synchronized. Logic changes can happen any time.

> I have one more question, so there is no way to

> dynamically generate SQL statement? I have to hard

> coded it in my program?

Yes. There are several options. At its heart, the solution revolves around java.sql.ResultSetMetaData. You can retrieve the column, table and schema names, the data type, its precision and scale, etc., such that you should be able to write a tool that will analyze a given table and generate the appropriate CRUD SQL statement for you.

Fortunately, many people have already done this. They are called O/R (or object-relational) mappers. Hibernate and JDO are popular now. You write POJO's (plain-ole-Java-objects) and annotate them with special Javadoc comments, and the tool will allow you to use the object to directly affect the database. (Caveat: not all databases, especially legacy databases, are the best candidates for O/R mapping). There are also some RDBMS-specific code generation tools available.

Other options are to use a JDBC-centric technology like i-BATIS, which is an easy transition from SQL. Or, finally, you can use ResultSetMetaData yourself to generate SQL statements for your RDBMS.

- Saish

Saisha at 2007-7-13 11:35:31 >