Nicolas,
Can you provide any metrics for the benchmarks when comparing Spring to AspectWorks? What exactly does "not good for Spring" mean?
/robert
Nicolas De Loof wrote:
I get such a case recently : we are using Spring as IoC container. On some situation we use a simple AOP interceptor.
Our customer have found on the net a benchmark comparing Spring vs AspectJ vs AspectWerkz. The bench result was not good for Spring (compared to AspectWerkz). The technical reason has no interest here, but my customer has warned us on this and expected us to make load test to confirm good application response-time (such load-tests had to be done in any case...).
Here is an example why we may not use some framework or function, not because it isn't the best, but just because customer doesn't agree (for some reason that may not be technical).
For info, load-tests have demonstrated Spring was good enough for us...
Nico.
Fogleson, Allen a écrit :
I think the biggest argument was stated by Nicolas.
I use struts because I like it sure, but I really use it because it is the framework that the client will accept and pay for and my developers know best. We recently used (portions) of Spring on a project and had a heck of a time getting the client to accept the app during user testing. Granted there were a bunch of other issues with this particular client that went against "best practices" but the major sticking point was Spring. (note we didn't even use the MVC part of spring even, just the beanfactory stuff)
Struts has of course gained popular acceptance so clients really don't think much about it when you say you are using it, vs something else. Al
-----Original Message-----
From: Dakota Jack [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 08, 2005 10:17 AM
To: Justin Morgan
Cc: Struts Users Mailing List
Subject: Re: MVC Frameworks
For my part, I still prefer Struts because I think it has a great potential if it endorses some move to IoC and does not fall off the strict web MVC pattern. I have no time for the event-based frameworks like Echo, Tapestry, JSF, Shale, etc. Others need that sort of thing. What framework you choose depends a lot on what you want to do, the sophistication of your developers, etc.
Jack
On Tue, 8 Mar 2005 08:44:26 -0600, Justin Morgan <[EMAIL PROTECTED]>
wrote:
Thanks...
I recently picked up Rod Johnson's J2EE Design and Development (ISBN: 0-7645-4385-7), and Chapter 12 is titled "Web-Tier MVC Design"... I'm going to assume this chapter is pretty similar to the one you mention.
I agree with you that this author is incredibly clear-minded, and I'm
soaking it all in. Most of the book is model-neutral, and focuses
more
on good practices and patterns, which is great because we have not
decided on a model yet. But in chapter 12 he only really discusses
Struts, Maverick, and WebWork. I was hoping for some commentary on
JSF
and Tapestry as well, especially regarding why one might choose one
over
the other.
It all boils down to two questions: 1. Why do you prefer Struts over any other web application framework? (Tapestry, JSF, Maverick, WebWork, etc) 2. Why should _I_ prefer <insert framework here>?
The second question is not meant to make anyone defensive; I'm just trying to get past
Thanks,
-Justin
-----Original Message----- From: Dakota Jack [mailto:[EMAIL PROTECTED] Sent: Monday, March 07, 2005 3:30 PM To: Struts Users Mailing List Subject: Re: MVC Frameworks
Rod Johnson (author of Spring and one of the clearest thinkers I have ever read IMHO) has a good discussion of the options in J2EE Development without EJB in Chapter 13: Web Tier Design.
Jack
On Mon, 7 Mar 2005 14:19:47 -0600, Justin Morgan
<[EMAIL PROTECTED]>
wrote:
Hi there,
I am currently researching different web application frameworks...
JSF,
Struts, and Tapestry specifically. We are planning to migrate a
large
existing web application to a rigorous model 2 standard using one or
more of these frameworks, and I am looking for more information on
the
differences between them. My research thus far has turned up only a
few
sources, and many of them seem religiously biased toward one of
them.
If any of you have opinions, or better yet, articles contrasting
these
technologies, please let me know.
Thanks,
-Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
