Let's break two of this forum's usual habits in one go. This is not a question, and it is not about Struts. It's about frameworks, and specifically about the benefits of Inversion of Control (IoC) which is the bread and butter of frameworks. Allow me to give you two examples. Consider the following JDBC code which selects the field FOO from the table BAR and processes the results:Never seen JDBC code like this? That's because it's way too cumbersome to write. Every JDBC developer is taking shortcuts in practice. But if you really want rock solid JDBC code that is guaranteed to close all its resources, is resilient against problems in the JDBC driver implementation and never allows exceptions to be obscured by subsequent secondary exceptions, this is more or less what you'd write. There's got to be another way, I hear you say. Well, there is. The idea behind Inversion of Control is that a framework imposes some structure on your code, takes care of all the boring plumbing for you, and calls ''your'' class to do the little bit of work that is specific to your application. This is the big difference between a framework and a library: you don't call the framework, the framework calls you. For example, using the Spring Framework, the code above reduces to:Quite a difference: less code to write, less scope for bugs, and no cutting of corners. I'm using an anonymous inner class here for the callback, but you can use an ordinary Java class if you prefer. If you're familiar with Struts, you know all about this type of thing. Struts Actions and ActionForms form the backbone of its IoC architecture. Inversion of Control can also be applied to application wiring and configuration. A typical Java application consists of many objects that work together to implement the required functionality; for example, a business object calling a data access object to get stuff done: There are a couple of problems with this. The business object is referring to a specific DAO implementation, and changing DAO implementations may mean changing such references in a couple of classes. Also there is no high-level "wiring plan" that allows you to see how your application hangs together; it's all in the Java code. Finally, additional configuration -- parameters, SQL statements and the like -- are likely to be pulled from property files or XML files on an ad hoc basis, or perhaps simply hardcoded in the Java source. An IoC framework such as Spring or PicoContainer makes it easy to remove this hard coupling:You can then use a configuration file to wire everything together and provide configuration information:You could change from the JdbcFooDataAccessObject to, say, a HibernateFooDataAccessObject without changing a single line of code. You might think, well, I'll never do this. Granted. But what about testing then? When writing unit tests for the business object, you will probably want to stub in a dummy DAO. With the original code, this is impossible. With the revised code, it is trivial. I'm barely scratching the surface here, but hopefully you'll see that this Inversion of Control thing -- i.e., frameworks -- can help you in much of your application development, and not just in building your controller and view! - Peter [ October 16, 2003: Message edited by: Peter den Haan ]
Well I've just started with Spring and the one thing that strikes me is that there are SO many different ways to do exactly the same thing: for example persistence. Consistency is a good thing(tm) you know.