say goodbye to "Collection"

[IPOz]

Hi,friends
I have developed multi-tier application using delphi for many years.The class "TClientDataSet" is my favorite ! She not only provides standard transportable data packet format,but also providing a unique way to operate data set.
After entering J2EE domain,i cannot find a similar way !The "Colloection" class doesnot provide uniform interface for the client side because the elements he contains may be very defferent! It is too complicate !
Recently i downloaded the rowset class library from sun website.And i feel the classes in rowset are very similar with "TClientDataSet"(maybe the rowset is developed by borland )
The following is some code snippet:
...
public class CoffeesBean implements SessionBean
{
...
private Connection getConnection() throws Exception
{
InitialContext initCtx = null;
initCtx = new InitialContext();
ds = (javax.sql.DataSource) initCtx.lookup("java:/SQLServerPool"

initCtx.close();
return ds.getConnection();
}
public RowSet getCoffees() throws SQLException
{
Connection con = null;
PreparedStatement stmt = null;
CachedRowSet crs = null;
ResultSet rs;

try {
con = getConnection();
stmt = con.prepareStatement("select * from coffees"

rs = stmt.executeQuery();
crs = new CachedRowSet();
crs.populate(rs);
// the writer needs this because JDBC drivers
// don't provide this meta-data.
crs.setTableName("coffees"
rs.close();
stmt.close();
}catch(Exception e) {
} finally {
if (con != null)
con.close();
}
return crs;
}

public void updateCoffees(RowSet rs) throws SQLException
{
Connection con = null;
try {
CachedRowSet crs = (CachedRowSet)rs;
con = getConnection();
// moves the changes back to the database
crs.acceptChanges(con);
}catch(Exception e) {
}
finally {
if (con != null)
con.close();
}
}
...
}
Isnot it simple?
At present the rowset is not a part of java extended class library however i believe she will succeed in the future!

What is your suggestion and comment?

Best Regards!
IPO_z@cmmail.com
Garbage in,Garbage out

 

[wushutwist]

Personnally I don't see where this is any better than a Collection, in fact I think it is worse. In this case EJB Users need to know the database structure in order to use the results of an EJB call. If you are just returning a Collection of data objects than they are hidden from the gory details of the DB. Furthermore, in almost all cases you, as a developer, will know the type of objects contained in a Collection that is being returned. The only exceptions to this rule are when dealing with a poorly Architected system. Good Architecture is key, if you don't have that then you are doomed to fail regardless of how data is passed around.

 

[IPOz]

>>In this case EJB Users need to know the database structure in order to use the results of an EJB call

Sorry! i donot think so.Using RowSet classes we will have one way to package data.The users donot need to know the DB structure in detail! They just need to know how to use a rowSet class as using Collection class.
when using Collection users must know how to use the element contained in collection.There are many ways to implement the element!

>>Good Architecture is key, if you don't have that then you are doomed to fail regardless of how data is passed around.

Yes but a standard data format is important too.If we use a standard data format(such as XML) then heterogeneous systems can exhange data easily.Personnally i think using XML to package data is a trend(there are XmlReader,XmlWriter class in rowset.jar)

Regards! IPO_z@cmmail.com
Garbage in,Garbage out

 

[wushutwist]

And when the database structure changes or the database provider changes then so must all the Client Code. Example: SQL Server has a Yes/No field that can be read in a ResultSet using getBoolean(), if the database changes to Oracle (Oracle has no Yes/No equivalent) then the client code must be changed to read a String. When using Value Objects the change can happen once in the Data Access layer and the Client Code remains unmodified.

Also, on XML. I think it is great for communicating between different Systems/Applications but for inter-Application communication I think it is overkill. There is always going to be more overhead when parsing XML Documents.

You keep saying that a Client needs to know the elements in a Collection. Sure, but they need to know as much (I would say more) to use a ResultSet "type" object. How hard is it to document a method and say it returns a Collection of User (or whatever) objects? Is performing a ClassCast that much of an inconvience?

 

[IPOz]

Thanks for your suggestion! You help me understand more about J2ee.
However i still think the client needs to be changed if the DB structre has been changed . Yes, the old client may still work by just changing only the data tier.But you always need to change the client to reflect the new DB structure in many situation,i.e. you will need to add a edit control if adding a new field in a table.

Moreover if we have a standard way to package the data then we can develop many data aware controls used in UI design.

Best Regards! IPO_z@cmmail.com
Garbage in,Garbage out