we are starting a J2EE system.this system need a lot of complex query,the query are based on a set of of user criteria.the combination of criteria is also complex.
there only a few updating.
what the good idea for the architecture?
to me,the O-R mapping looks hard for this system such as CMP,JDO, habernate...
the DAO layer will be very complex too,,but others layer will be very simple such as business.basiclly,just run big query and return result to browser.
please your idea for the architecture.
Fortunately or Unfortunately J2EE platform provides multiple choices of solving the same problem. (BTW I think choice is a good thing). In your case O/R mapping or fetching the data back based on complex query criteria.
As you mentioned there are many choices like CMP EJBs, O/R frameworks, Design patterns like DAO etc..
Depending on the usecases, you could have a mix. you can have a set of O/R mapped classes that allow you to do report queries based on complex criteria and some DAO to perform direct query using JDBC.
O/R Frameworks like TopLink allow to do O/R mapping and construct complex queries using different query mechanisms. (SQL, EJB-QL, Expresssions). Using frameworks typically yield less code to maintain and are proven to solve the problem for long time.
Last but not the least, IMHO, we should not forget that databases are good at crunching data. Though we are building J2EE apps, we should try and leverage database features like stored procedures as and when possible and let the database do what it is good at.
ORM tools are not usually effective (in terms of performance and system resources consumption) if you need to read lots of data from the database. So, if you expect your queries to return several handreds rows or more you should think about something else.
I also suspect that ORM tools are not flexible in building complex queries.
I would suggest considering 'JDBC For Reading' pattern for search queries and "Data Transfer RowSet' for data transmission to the presentation tier (see EJB Design Patterns book). You can also consider using 'Value List Handler' pattern if you do not need clustering (see http://java.sun.com/blueprints/corej2eepatterns/Patterns/ValueListHandler.html
I would also suggest moving queries to stored procedures to isolate your code from query complexity.
Thank you for all your suggestions.
since the querys are complex.looks like only the DAOs will be very heavy. however, the business delegation,business facade,business layers are almost empty.they are almost like just some getXXX() method calling from layer to layer,
and the rowset been transfered from layer to layer.is my understanding about patterns correct?
In general, yes, you are right.
I would also suggest placing queries in stored procedures. In this case:
1) your DAOs will also be simple and clean
2) it will be possible to modify queries without changes in code, recomplication, redeployment, etc.
for most of query, I don't need business layer such as delagate,facada,even DAO is simple.
should I remove all of this layers from application?
I want use struts for web tier since MVC is best pratice for web tier. but if I use rowset to transfer data,what's the best way integrate rowset into struts since struts basiclly use beans,I need to convert rowset to collection of beans?
I see the following two simplest ways:
1) writing a custom JSP tag that goes through the rowset and renders it. It will allow you to avoid excessive object creation.
2) writing a custom collection backed by the rowset and a java bean with using the flyweight pattern (see GOF book), again, to eliminate excessive object creation. It means that iterating over the collection always returns the same bean instance with different data.
Moreover, if you do not use EJBs then you could use JDBC ResultSet directly instead of RowSet. RowSet is good when you need to transfer tabular data from the business tier to the presentation one. Otherwise, it is more effective to use JDBC ResultSet.