Jato & Struts

无意间看到 JATO 的作者写的这篇文章：
不想争论什么，只是开阔一下视野~~

When I read your post, I was concerned that you were under some
misapprehensions, and so wanted to make some clarifications.

Before continuing, I want you to know that the decision to go with any
particular choice of architecture/implementation is entirely yours, and
we're fine with whatever you choose--if Struts is the right way to go in
your company, that's great. However, I'm not sure you're seeing the whole
picture when I hear you are considering a double migration, or a migration
from JATO to Struts.

> We use the STRUTS model-view-Controller implementation of APACHE. I
> believe it is quite possible to "take away" the JATO presentation
> layer and its taglibs. JATO offers a VIEWBEAN wrapper to contain the
> model object, which holds the STATE. The JATO presentation layer
> renders and manages this STATEobject/model through the wrapper.
>
> In STRUTS this is implemented quite similar. Has anybody tried to
> "take away" certain layers in JATO and replace them GRADUALLY to get
> to ANOTHER target architecture??

First, let me say that Struts is a fine set of classes for building your web
applications, and I have nothing against it--I don't want this message to be
viewed as a religious argument. However, I don't want you to hear Struts
say it's "MVC" and us say JATO is "MVC", and think that the two are
equivalent. Far from it. Let me explain some of the more obvious
differences.

Struts has a very different, narrower perspective of what makes up a view
than JATO does. In Struts, a view is nothing more than a JSP that uses the
Struts taglib. This is straightforward, and works great for simple pages,
but if you've used JSP at all, you realize that real world apps frequently
need to do much more complex rendering. JATO provides far richer facilities
to assist in the rendering of repeated/tiled regions a variable number of
times, perform conditional tests, dynamically rewrite large portions of HTML
at runtime, and construct complex HTML objects (combo, list boxes and radio
button groups).

JATO also provides an easy to use, powerful, and efficient event model which
allows developers to place more complex presentation logic inside of a
helper view bean class, where it belongs. Unlike Struts, this allows the
JSP itself to remain clean and free of code, which is consistent with widely
accepted best practices. The event model also promotes consistent,
structured develpment accross the application, since all developers will
work within the same well-defined development structure. Struts lacks an
event model of any kind, and therefore Struts developers will tend to embed
presentation control logic directly in the JSP. While this works for
simpler applications, it can easily get out of hand and lead to an
unmaintainable mixture of HTML and presentation logic.

While Struts does a good job of supporting localized dynamic values, it
doesn't provide any support for using localized parallel content. Parallel
content is the idea of using different JSPs localized for a different
language, or written using different markup than HTML, like XML or WML. For
example, if you need to add a parallel page that renders a French version of
a given page in Struts, the embedded display logic from the original page
would need to be included and maintained in the parallel page. This
compounds any maintentance issues with the original page. JATO, however, by
factoring display logic out of the JSP and allowing views to dynamically
decide which view to display to the client, allows transparent switching
between parallel content. This capability ensures that the presentation
logic of the application exists in only one location regardless of the
content rendered to the client.

Struts also has very little room for reusability beyond large, coarse chunks
of code (actions & form beans). There is no provision for hierarchies of
views or forms, fine grained view objects & events, nor any facility for
reusing portions of a view in other views. All of this, however, is built
into the core of JATO, meaning that you define building blocks (think "web
beans") that can be arbitrarily composited to form functional web
applications, much as you would composite Swing graphical components to
create a client-side Java application.

One example is that each HTML form in Struts must be associated with a
single, flat ActionForm bean, meaning that portions of that form cannot be
reused anywhere else in the application (or another application for that
matter). One real world application we encountered recently has a single
page with upward of 250 display fields, arranged in a hierarchy of over 30
tiled views. Imagine the complexity that would be necessary to replicate
this in a single Struts ActionForm bean, including all the necessary flags
needed to control conditional rendering of that form; however, the JATO
version has separate classes for each of the container views, providing
scope to the fields contained within, and which can be rearranged and reused
as desired.

Struts provides no formal notion of a model. Instead, anything not
specified by Struts is considered a "model"--a very loose definition prone
to interpretation by every project and developer. This leaves you, the
developer, to write all the manual code to obtain data, and hook up your
view so that it can display that data. It also provides no contract between
the Model and the View-Controller components of the architecture, so that
interaction between them is limited or custom to each project or page.

JATO, however, formalizes the concept of what a model is and does, and how
controlling logic interacts with it. Lots of different things can be viewed
as a model--a SQL query, an EJB, an individual EJB method, a SOAP procedure,
the HTTP session, a JavaBean... you get the idea. JATO provides a standard
way for controller *and* view logic to interact with a model, and thus this
interaction can be automated.

For example, JATO formalizes SQL queries as QueryModels. QueryModels can be
automatically executed in response to a high-level user action or on the
display of a page, without any developer code necessary to manage the
execution or its results. By contrast, if you want to execute a query in a
Struts application, you write regular JDBC code...and then you write it
again, and again, and so on, everywhere you need to access the database.
There is no facility for automatically managing SQL statements, dynamic
user-level WHERE clause criteria, multiple rows of result set data,
connections, etc. JATO provides all of this--if you want it--out of the
box. Or you can do exactly what you'd do with Struts (or for that matter,
what you'd do in any J2EE application) in JATO. The difference is that in
JATO, you have the choice, where with Struts, you always have the task if
implementing it yourself--and you *will* have to implement this in order for
enterprise development to scale.

Finally, realize that Struts and JATO, though very different, are compatible
in two ways. First, the JATO development model essentially collapses to the
Struts development model if you don't use any of the additional features
JATO has to offer. JATO gives you a wide range of features to choose from,
both low- and high-level, but only prescribes a very minimal set that is
equivalent to that prescribed by Struts. Second, both JATO and Struts
applications are just J2EE, so there doesn't have to be a pitched idea of
one versus the other within an application. The JATO 1.1 documentation
lists several ways of interoperating with a JATO application from outside or
within any other J2EE application.

In summary, J2EE development using Struts is a small subset of J2EE
development using JATO. If Struts is compatible with your internal
architecture, so is JATO, meaning that there's nothing in JATO that would
prevent you from doing the same things you would do in Struts. However,
JATO gives you much expanded options and a more logical and flexible
contract between application entities that make your applications more
consistent, quick to develop, and easy to maintain.

So, while you could probably find a way to rip out portions of your migrated
JATO application and replace them with Struts, I don't know how that would
be beneficial at all. Not only would you be giving up all the additional
power that JATO provides that Struts does not, but doing so for little more
than unnecessary consistency.

Inevitably, frameworks will differ based on the tasks and problems they try
to address. JATO was designed and built to be enterprise strength,
extensible, fast, and rich. In short, Struts and JATO are two very
different frameworks, and the two can't be compared as if they were
equivalent. Please don't make this mistake during your migration
evaluation.

Todd