21. Conclusion

Let’s review what has been presented in this document:

• the basics of web programming in Java using servlets and JSP pages
• an introduction to MVC architecture
• an introduction to the 3-tier architecture
• an introduction to Spring IoC
• examples to illustrate these points

We believe that readers who have reached this point are ready to develop their own Java web applications. They are also ready to tackle other development methods similar to those covered in this document. Let’s review the architecture of the web applications developed here:

For simple applications, this architecture is sufficient. Once you have written several applications of this type, you will notice that the servlets of two different applications:

1. use the same mechanism to determine which method [doAction] to execute to handle the action requested by the user
2. in fact differ only in the content of these [doAction] methods

The temptation is then strong to:

• factorize the processing (1) into a generic servlet that is unaware of the application using it
• delegate the processing (2) to external classes, since the generic servlet does not know in which application it is being used
• link the action requested by the user to the class that must process it using a configuration file

Tools, often called "frameworks," have emerged to provide developers with these capabilities. The oldest and probably best-known of these is Struts (http://struts.apache.org/). Jakarta Struts is a project of the Apache Software Foundation (www.apache.org). This framework is described in (http://tahe.developpez.com/java/struts/).

The Spring framework (http://www.springframework.org/), which has emerged more recently, offers features similar to those of Struts. Specifically, this refers to its Spring MVC module. Its use has been described in several articles (http://tahe.developpez.com/java/springmvc-part1/).

Spring does not stop at the MVC concept of the [web] layer of a 3-tier application. It is useful even in applications outside the web.

Thus, we concluded our course by implementing an MVC architecture within a 3-tier architecture [web, business logic, DAO] using a basic example of managing a list of people.

In version 1 of the application, the list of people was kept in memory and disappeared when the web application was unloaded. In the other versions, the list of people is stored in a database table. We used four different DBMSs: Firebird, Postgres, MySQL, and SQL Server Express.

Thanks to Spring IoC, the [web] layer from version 1 could be fully retained in subsequent versions. We thus demonstrated that it is possible to build n-tier architectures with independent layers.

With the versions using a database, we demonstrated Spring’s contribution to building the [DAO] and [service] layers. Thanks to Spring’s integration with iBATIS, we were able to build four versions that differ only in their configuration files. The same [DaoImplCommon] class was used to implement the [dao] layer in all four versions. To address an issue specific to the Firebird DBMS, we had to derive this class but did not need to modify it.

Finally, we demonstrated how Spring allowed us to manage transactions declaratively at the [service] layer.

Readers are encouraged to explore the full range of features offered by this product.