 | Mailing List | | Home | | Forum Home | | JBoss - Java Application Server | | Struts - A MVC web framework | | Tomcat - JSP/Servlet container | | iText - An open source PDF Java Library | | JDOM - JDOM XML Parser | | J2EE - A mailing list for Java(tm) 2 Platform, Enterprise Edition | | J2EE Pattern - An interest list for Sun Java Center J2EE Pattern Catalog | | Servlet - A mailing list for discussion about Sun Microsystem's Java Servlet API Technology | | JSP - A mailing list about Java Server Pages specification and reference | |
Struts & Hibernate
|
|
|
| | | AW: How to realize extendable data objects? | AW: How to realize extendable data objects? 2003-09-24 - By Udo Cirkel
Back
Hello all,
thanks for your suggestions!
Keely: Yes, your understanding of the scenario is correct...
...and there is one more dimension of my problem to think about:
The material data has to persist in a database. The initial
database representation should be a table with a column
for each attribute of Material. The sense of this requirement
is to allow sql-queries about the attributes of Material.
When deploying a new module how to achieve an appropriate
extension of the database schema? Appropriate means, that the
new database representation of Material and the added attributes
can be queried, too (one goal is to provide an user-interface
for auto generating sql-queries; these queries should possibly
work about all - initial and new - attributes of Material).
Which approach is appropriate to realize the access to all
material data/attributes over a general access class?
Please read this mail in conjunction with the first one.
Thanks in advance, Udo
-- --Ursprungliche Nachricht-- --
Von: An interest list for Sun Java Center J2EE Pattern Catalog
[mailto:J2EEPATTERNS-INTEREST@(protected)]Im Auftrag von PavanKumar
Keely
Gesendet: Dienstag, 23. September 2003 18:28
An: J2EEPATTERNS-INTEREST@(protected)
Betreff: Re: How to realize extendable data objects?
If my understanding is correct,
Existing scenario: If new module is installed then
Material has to be changed according to the new module
( adding attributes etc )
Many modules in the application will use this Material
object. Making this Material Object an instance of
Hashtable/HashMap can solve your problem. Because you
can just add one more attribute to this as simple as
that and use that attribute in the new module. But one
problem with this approach is we need to stick to the
standard key names throughout the application. But
avoid hardcoding the key name and use some
initialization file, which will be initiated at the
start of the server. This solution is on the lines of
EJB Design pattern "DTO using HashMap".
One more way of achieving extendibility is using XML
data object. Whenever you create Material object that
should form the data in the XML. But one problem with
this approach is building XML and parsing the XML.
if you have any queries or if you get a better
solution than this please do let me know.
thanks and best regards,
Keely Pavan
TATA Consultancy Services, Bangalore
__ ____ ____ ____ ____ ____ ______
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.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@(protected)
====================================================================
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@(protected)
|
|
|
