Re: Suggestions welcome

Message

Yes I also agree to what Aaron Tubman has said and I have implemented the same for a similar problem.

And the soln worked very well.

If the application demands that the Db be changed frequently then better look into the design of the application because this should not happen.

In case you have some constraint that the schema needs to be changed as the DB is outside your control then in that case you should build a Schema Map generator(generates the schema in XML) with a Schema mapping table where the application level mapping should be present and the java persistance code you write should use your schema mapping table to link the application methods to the new column names , and the schema mapping table info can be extracted dynamically from the schema map XML (similar to the deployment descriptors and to do this you can use the java Metadata class). But inorder to write something like this you have to write a querry builder of your own too. Well I have put my thoughts I dont know whether it will make much of a sense for you. You can go to the net and find lot of links on working with schema maps, try to take some help from there.

Last option offcourse is have a schema which you store in the DB. DBSchema and the data in the XML form is stored in the DB itslef. and you need to parse the data XML using the Schema XML but I feel performance will be substantially low if the Schema or the data XML are very big.

All the best.

Rgds

Deb

-----Original Message-----
From: An interest list for Sun Java Center J2EE Pattern Catalog [mailto:J2EEPATTERNS-INTEREST@JAVA.SUN.COM]On Behalf Of Aaron Tubman
Sent: Thursday, March 25, 2004 1:52 PM
To: J2EEPATTERNS-INTEREST@JAVA.SUN.COM
Subject: Re: Suggestions welcome

We solve simmilar problem in the following way:

We use DAO patterm with TO where DAO hide the DB access and its API provides TO that carry the data between entities. In this case you main interaces will not change when you add or remove fields. The overhead in this case is that you always fetch from DB all the data relevant for the TO. I think that this is minor overhead.

Aaron

-----Original Message-----
From: An interest list for Sun Java Center J2EE Pattern Catalog [mailto:J2EEPATTERNS-INTEREST@JAVA.SUN.COM] On Behalf Of Maya menon
Sent: Wednesday, March 24, 2004 11:54 PM
To: J2EEPATTERNS-INTEREST@JAVA.SUN.COM
Subject: Suggestions welcome

All,

I need help in this situation. We have to develop an enterprise application ( a web site) using J2EE technologies. I was planning to use, Struts and J2EE patterns.

Now, it looks like our database will be frequently changing. The changes can include, dropping a field, adding a new field, dropping a table etc.

In this case, which is a good design for handling back end ?

I was planning to use Entity bean,facade and Transfer object.

How does it sound ?

Thanks

Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time. ==================================================================== Companion Site: http://www.corej2eepatterns.com J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@java.sun.com

==================================================================== Companion Site: http://www.corej2eepatterns.com J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@java.sun.com

Re: Suggestions welcome

Debasish Halder

2004-03-25