This post originated from an RSS feed registered with Java Buzz
by Marc Logemann.
Original Post: Spring/Struts/Kodo for next project
Feed Title: Marc's Java Blog
Feed URL: http://www.logemann.org/day/index_java.xml
Feed Description: Java related topics for all major areas. So you will see J2ME, J2SE and J2EE issues here.
I finally closed the evaluation and testing phase of the included frameworks and product my next web based project. Its like expected and here are the results:
Spring (mainly the IoC/AOP layer)
----------------------------------------
I clearly wanted to have support in seperating my layers and dont wanted to deal with all the Singleton, Factory and Pattern stuff myself. Spring does help me with that in a big way. Declarative wireing of the components and out of the box support for singletons and other patterns. This combined with the JDO Helper stuff also shipped with Spring will increase productivity and readibility in the long run. Even knowing that there is some learning effort upfront.
KodoJDO
-----------
I have been evalutating Kodo for a long time now and worked with IntelliBO from Signsoft before. So JDO as persistence spec was allready targeted. Kodo got the vote because of its high visibility in the community and the specs. Furthermore i think that the folks working at Solarmetric are quite skilled when it comes to persistence. This is at least what i think when i read comments or articles by Abe, Robin or Patrick.
Struts
-------
This was the candidate most likely to be removed from my evaluations in favor of Spring MVC, but i really wanted to use CommonControls out of the box and to be honest, i wanted to have at least one part of the overall architecture where i have some experience with. And you cant make anything wrong by chosing Struts. Its not the best thing since sliced bread, but its a well known companion.
CommonControls
---------------------
A really nice JSP Component package for everyday things like tables, forms, trees and more. You can create those things by yourself but i dont want to. Like i said, the only drawback is the sole focus on Struts.
Reasons to use this architecture
-------------------------------------
The resulting piece of software should be able to run under various conditions. I dont want to force customers to buy a J2EE application server and i dont want to force them to use some special database. Nevertheless i needed a declarative approach for transactions and wireing components. And i wanted to be able to expose some of the business beans as real webservices. I think this can be achieved with my current architecture.
What i really want: Concentrate on my business goals which are hard enough to meet.
Previous Topic
