> -----Original Message----- > From: Rick Reumann [mailto:[EMAIL PROTECTED] > > > Trust me this isn't an attempt to open up a whole flame war. I'm just > curious how many of you have messed with Spring and what your > thoughts > concerning it are. > > I've been looking at it some and I do see some strengths it has, but > some of those strengths I also see as potential weaknesses (maybe). > > In my short study (and I mean very short:) of Spring, here's > what I've > been thinking so far... > > (Note, Spring handles a lot more than the just the front end > framework, > but since Struts is mostly a front end framework these comments about > Spring are in relation to the web component portion of Spring). >
I wrote a basic bean to test the idea of the Bean Framework. The idea of objects "springing" to life from an XML configuration file with all the dependencies between the beans intact and correct is very nice. I think there are two weaknesses to be aware of. First, I can see where there is a paradigm shift for traditional functional programmers. Second, a new developer also must read XML configuration file and be able to visualise dynamically to understand a new project. > Flexibility. Here is where I think Spring's major strength > lies. You are > given some out-of-the-box controllers and stuff but how the > application > is put together with the framework allows for a lot of > flexibility. In a > large corporation, though, this all could be a weakness if one isn't > careful. It seems very easy to have part of an application > being coded > using entirely different Spring concepts than another part. > Struts has > this problem as well, although it appears more difficult to > abuse since, > unless you start really doing funky things in Action execute methods > (seen it done), it's pretty easy to stay within 'best > practices' guidelines. > Can you go into a bit more detail about these abuses please? How is the application coded differently? Are you talking about actual API differences or idiomatic styles? > Learning curve. I can't really tell which is an easier > framework to pick > up and learn. I've been working with Struts for a long time > now, so it's > difficult for me to look at this objectively. The fact that > there are a > lot more ways of developing web applications with Spring can > be somewhat > of an obstacle for picking it up quickly. > This is a problem for any framework. A developer evaluating asks 1) What is this framework suppose to do? 2) How does this framework really help me? 3) Will it in fact hinder me in the long run? 4) Are there any examples and support out there? > View tags. I happen to like the basic struts html tags > related to forms. > Spring doesn't come with much of a tag library that I can > tell. I'm not > sure how tags such as the Nested tag will play with Spring. Currently > you have to provide all form field values with JSTL... not a big deal > except a bit unwieldy for nested beans (imo). > > Lack of ActionForms. Spring doesn't use ActionForms and I > like this. You > can tie a Value Object right to your front end form. Very nice. If > Struts got away from ActionForms I'd be very happy (although I'd lose > some of the nice html tags functionality). I did not agree with Rod Johnson put down on ActionForm beans in his book "J2EE One-one-One Design". I agree with Craig McClanahan reason that the ActionForm should be in fact buffer of HTML Input, that only exists inside the presentation tier/layer. I think Rod Johnson missed the important point, that the presentation tier saves the user's input (whatever it is) and that its aid validation effort. ValueObjects are not where you should be writing validation code. It is interesting if this design rule will change with EJB 3.0. Probably not, it will be a still Data Transfer Object (Value Object) delegating to POJO or full blown Entity EJBs 2.0. > > Spring also uses a lot of cool stuff like IoC (Inversion of > Control/Dependency Injection). > > Right now, as it stands, I'm finding it difficult to justify > switching > over to 'yet another framework' (Sheesh how many are there > now - Spring, > WebWorks..:). I've run into some limitations using Struts > (such as its > nice handling of a 'form wizard flow' where you might need to action > chain - gets a bit ugly) but overall I don't really have many > complaints > about Struts. It appears that I'm not going to gain that much > switching > over to Spring. A lot of my good buddies in #FunkyCodeMonkey on > darkmyst.org are former Struts users and they seem to like > Spring better > - although, they haven't given me enough compelling reasons > to jump ship. > Not mention that Spring has its own MVC layer within the framework itself. I think the real destination is where will JSF and Struts juxtapose in the future. I would assume that I will be probably using the following this time next year 1) JSF 1.1 or better 2) JSTL 1.1 (Tomcat 5.x / BEA WebLogic 9 / JBoss 4 ) 3) Struts still I am not sure if Spring MVC layer has support for migrating to JSF. > I've only begun to start looking into Spring so I'm sure I'm > missing a > TON of points that could be made. I'd appreciate any other > comments good > or bad concerning either framework. I'm sure many of you fall > into the > same frustration-boat that I feel like I'm in- "So many > technologies out > there - only so much time." I've trying to determine if I > really need to > be investing the time to explore this framework more when I could be > exploring other things I need to learn more about. I'm sure > many of you > can relate:) > > Thanks, > > -- > Rick > That's all part of the fun of technology. It just never stops, because somebody out there is pushing it along. The one thing that has Struts out for almost four years is the design principles are rooted on solid foundations. You cannot go wrong with a framwork that implements the J2EE blueprints and does it very well. FrontController, Application Controller, Model View Controller, View Helper, Service to Worker There are probably one or two others I have forgotten that are not strictly pattern merely idioms: Digester XML, Bean Utils introspection. -- Peter Pilgrim Operations/IT - Credit Suisse First Boston, 10 South Colonnade, London E14 4QJ, United Kingdom Tel: +44 (0)207 883 4447 ============================================================================== This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. ============================================================================== --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
