我借花献佛，也转 post 一篇 Jato vs Struts 开发的经验。
一位Senior Java Architect，在他们公司的不同项目中分别使用了 Jato 和 Struts 构建项目后，写了这篇文章。我想大家可以做个借鉴吧。
==============================================================
Todd and JATO Team,
First of all, thank you very much for the support and prompt detailed
answers. Our industry-class and enterprise-scale application
(finance) is successfully running in production (SunOneServer/JATO
1.2).
JATO performs extremely well (even combined with our original very
fat object framework encompassing session management, workflow
processing, business rules engine, etc., etc.). Moreover, there is no
performance degradation for large number of concurrent users.
Extremely large and over-loaded with business logic pages (JATO's
very thin JSP is over 150K!, e.g.) just fly and it is hundred percent
dynamically multilingual (parallel content!).
A couple of notes regarding to the discussion JATO vs. Struts or vice
versa, since another application of the company uses Struts framework
and we could compare.
1. If application should be migrated from ND to J2EE (probably it is
a closed stage in the industry) it must be JATO (iMT tool does its
job very well).
2. If the application should be written from the scratch the
demarcation line is the size and complexity of the project. For any
enterprise size and complex application it has to be JATO as well.
Formalized model and event driven architecture allows easily
implement/include/add the best design patterns throughout the
application. Elimination of thread safe programming for developers
leads both to rapid bug-less development and good performance under
load (much better to refer to the originators' articles). From my
personal point of view, JATO has modern, very balanced and extensible
architecture and it is just nice to work with it.
3. For small/medium size application it could be either one or
another. It really depends on different factors (further company
goals, staff skills, staff education time, etc., etc.).
Now why I am using JATO abbreviation, not S1AF. There is still no
official announcement from Sun with regards to the S1AF code access
(please correct me if I am wrong). Conversion of the JATO 1.2 based
project to S1AF is not easy if the project integrated with non-Sun
IDE (in our case, we have JBuilder). Thus, it is could be a critical
to get this answer. Personally, I prefer to stay with JATO 1.2 (even
without interoperability with the code generator GUI) having the
access/control to the framework rather than to use reliable GUI as a
black box.
Please do not consider this as a criticism. I just don't know
details, it is totally out of my responsibilities, and I would like
to be wrong with my assumption. Nevertheless, from my point of view,
closing of the access to the source code could probably hurt S1AF's
market expansion. Struts source code is open (and will be open) by
default and this is the today's mainstream. JATO is very good and
matured, but not easy beast and one of the most efficient way to
learn it is to read the code. I definitely know, that people choosing
the MVC framework in the industry has been already taking this factor
into account. It doesn't mean, of course, that the GUI tool itself
should be free.
Let me be more precise with some historical excurse. NetDynamics
policy was to close the access to the source code and use it as a
black box (with a very good set of documentation). It was a common
practice in pre-J2EE time, but took a lot of extra hours to get the
result sometimes. Who knows where the NetDynamics would be if they
had chosen opposite approach.
Finally, thank you very much again for such a good product. Every
single word in the white paper is true. If I have any choice for my
further projects, I will stick with this state-of-the-art MVC
implementation (JATO or S1AF) again.
Vladimir Ivanov,
Senior Java Architect,
Ph. D. in Applied Mathematics