Problem: For frequent query operations � like for fetching values that populate combos in every page in our application � will it be advisable to put the stored proc call in the ActionClass directly, or in the usual manner, traverse across the tiers to put the call in the DAO? If SP calls are executed directly from the Action class, will it speed up the application for frequently-required queries? In your opinion, how will this impact performance if in future the web and business tiers are separated onto 2 different appservers?
For mostly static data, what other options are available to avoid re-querying? Any suggestions will be appreciated. TIA.
That because logic is spread out over a number of objects, it will perform significantly worse than logic in a single object. This isn't true. Method calls are very fast, and do not significantly impact performance. Creating instances of objects takes a little longer, but this can be controlled by designing objects as singletons, caching them, etc.
That it's OK to sacrifice good design on the altar of improved performance. Even if a multi-tiered application did perform significantly worse than a single-tier application, I'd still opt for the multi-tiered application because it's a better design choice. A poorly designed application has costs that go well beyond performance costs.
This is not to say you shouldn't keep an eye on performance: just don't sacrifice good design for the sake of performance.
In your opinion, how will this impact performance if in future the web and business tiers are separated onto 2 different appservers?
Granted, it's going to take a little longer if you have to make a network call for your business methods. This can be minimized by using Transfer Objects, and other J2EEpatterns. The most important concern is: do you really want some of your business logic in one tier and some of it in another?
For mostly static data, what other options are available to avoid re-querying?
One option is to cache this type of data in application scope using the ServletContext object. Data such as states, countries, colors, etc. are the same for all users, and they don't change very often. Query for them when the application first starts up and put them in application scope. This can significantly reduce calls to the database. The one drawback of this approach is that this data remains cached as long as the App Server is running. Even though the data changes infrequently, it does change sometimes. To get around this, you may want to set up a timed process that refreshes this data once a day or as often as necessary. [ April 30, 2006: Message edited by: Merrill Higginson ]