Jato & Struts

03-09-10 iceant
无意间看到 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

猜你喜欢