Good insight - thanks for the comments.
> 1) "Object explosion" for large sites--1-to-1 mapping of URLs to objects
can
> lead to hundreds of small classes. It really bothers me that Struts
> encourages this kind of situation. Although the DispatchAction helps a
lot.
The value Struts adds (and why 'object explosion' doesn't bother me
personally) is:
o It allows you to write 738 components instead of 738 pieces of business
logic PLUS the code to coordinate and organize the 738 pieces. All
components
are similar in structure and usage - so it's likely that libraries of
"helper
classes" will be re-used among many of them.
o Since all 738 pieces would be written similarly, managing your
development
resources should be easier; that is, you've seen one Action class,
you've
seen 'em all. Imagine what 738 pieces of business logic coding would
look
like if there was no framework that they plugged into. They would all
look
different, with different calling methods and signatures. They would
pass
and coordinate data differently - all depending on who wrote them. If
you
have 738 Action classes that are similar in structure then you'll save
huge
amounts of time.
o Since all 738 components would be pluggable into the framework by
updating
the config files in XML, staging various large pieces into QA and then
production
is much simpler. Alternatively, you would more tightly couple individual
components to the code that manages them (i.e., the framework) and then
change becomes more complex and bug prone.
> 2) Meaningless method signatures, like execute(Mapping, Form, Request,
> Response). All the methods look the same, regardless of what data they're
> actually expecting. This often makes it necessary to go into the Java
code
> just to figure out what data a method uses. Not to mention losing
> compile-time type checking.
In general I believe having all the methods look the same is a benefit; the
alternative is having them all custom fit and prone to ongoing change. I've
not noticed compile-time being a significant problem personally, though the
apps I work on are broken down into smaller groups - I only build a subset
of
our overall stuff at a time.
> Being a Java/OO purist, I really don't like it when 738 type-unsafe,
> throwaway objects (or methods at least) make their way into the Java
object
> model. I have grown to recognize that large amounts of such code are
> necessary in any large website, but if I can help it I would like to keep
it
> out of the Java source for the above reasons.
Again, I think that having 738 components all extending the same base class
is much easier to manage than 738 customized, tightly-coupled components.
And I don't think that from an OO perspective this is necesarily a
negative.
In essence, the time saved by making the components all similar so people
can more
easily pick up and/or reuse each other's code I believe makes up for any
inherent
inefficiences that may exist because each component isn't built to custom
spec.
> I have started writing some code that pushes the messy code out of Java
and
> into an XML file not unlike the struts config file. However, I've only
just
> begun really concentrating on this problem, and don't have any experience
...
>
Before you write something that does what Struts does because you're not
sure if
you like it, try it out. Some things you may not like initially may grow on
you
once you've used it enough to undertand why it's built the way it is. I'm
not
saying it's perfect - anyone will tell you there's room for growth. But
it's a solid
framework with a large user base pouring over the code finding bugs and
making
suggestions.
Consider that the committers on this team have a great number of years
between them
of experience building web-based applications in Java. Plus the feedback
that comes from having the broadest user base of any similar framework.
Plus the
advantage that the Apache Software Foundation and other of the people on
this project
are involved in ongoing development of Java itself through the www.jcp.org
Not that I'm an expert, but I've used it and, like you, have built both
large
and small apps as well.
HTH,
Kevin
http://www.amazon.com/exec/obidos/ASIN/0672324725/qid%3D1029268761/sr%3D1-5/ref%3Dsr%5F1%5F5/102-6207683-1524955
---------------------------------------------------------------------------
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure. If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---------------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
