Posted by jhook
on February 8, 2006 at 2:48 PM PST
Everyone assumes JSF adds overhead to application processing on the web versus something like Struts or WebWork. Reflecting on experience, I think JSF can actually be a lot faster than those solutions.
With traditional Action MVC frameworks (Struts), you have a specific set of scopes to store state in over transactions: request, session, and application. Often, while developing applications with Action MVC frameworks, you have to make a decision to store objects/state in the request or the session. There can be consequences to the the performance of your application in either case. You can go the transient route and just retain state for a request cycle, or you can live with and manage it in your session.
Let's disect a request to an MVC application-- when you compare the time your in-memory Java code takes compared to DB calls, often times, the time spent by the MVC framework is marginal-- JSF or Struts. So we go back to trying to fix performance with the DB by either specializing operations in the request or storing results in the session.
JSF has acted as a foundation for frameworks like JBoss Seam and Oracle ADF because it provides context to user interactions. These contexts can be used to scope cached data in more meaningful processes without committing to a full transient (request) or persistent (session) solution. It becomes much more practical to store results from the DB within the context of a particular paging table component, avoiding the 600ms->20sec DB queries. I hope you see my point.
Take a look at your caching strategies and ORM mappings-- what's driving those fetch policies and associations? Are you making decisions to not-lazy fetch an association because you display it with the parent object? I would say that a lot of your decisions around caching/fetching policies is formulated by what's being coordinated in the presentation. Doesn't it make a lot of sense then to have a MVC solution that retains and manages those contextual associations for you?
Now, pair that meaningful, contextual state management with encapsulated AJAX components that can communicate back to that managed state without 'requiring' DB calls for partial requests....