Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Model-View-Controller Web frameworks for Java are plentiful, and most of them integrate with Spring, but the tightest integration can be found in Spring's own MVC module. Get started with Spring MVC in this introductory article by Steven Haines, who begins with a history of the Model-View-Controller paradigm in Java Web development. He then introduces the Spring Framework and explains how it leverages the concepts of Spring, including dependency injection. Finally, Steven guides you through a programming tutorial that demonstrates the core features of Spring MVC in an easy-to-follow, hands-on format. Level: Beginner
In the ongoing evolution of Java EE technologies, the Spring Framework has emerged as a top choice for the middle, or business tier of enterprise application development. Spring's lightweight paradigm for developing enterprise applications has won it a large following that today rivals that of the standard Java EE platform. As a result, most MVC (Model-View-Controller) Web frameworks integrate with Spring, including Spring's in-house module, Spring MVC. If you're developing Spring applications for the Web, familiarity with Spring MVC will help you step up your game while also leveraging all the familiar benefits of the Spring Framework.
To provide a context for understanding Spring MVC, I'll start with a brief history of Java Web applications, followed by an overview of the Spring Framework and its business value. I'll then introduce Spring MVC and walk you through a development project: a mini content-management system (CMS) that demonstrates how to build and deploy a Spring MVC application. You can download the source code any time.
This brief history begins with Java's entry into Web application development: the Servlet API, introduced in 1997. Before then, developing dynamic Web applications with disparate APIs and programming models proved to be challenging. (I'll resist the urge to recap the old days of CGI, the futile battle between Netscape Server plug-ins and ISAPI plug-ins, and all the homegrown APIs.) The Servlet API provided a standard on which vendors could build Web containers and developers could implement a simple programming model for constructing Web pages.
With servlets, dynamically constructing HTML documents became easy. But because the documents were constructed inside Java source code, maintenance was challenging. For example, changing a font or moving a piece of content within a page required you to update the HTML inside the servlet code and then recompile and redeploy it to the container.
Sun resolved this issue in 1999 by introducing JavaServer Pages (JSP). Rather than implementing presentation code inside servlets, JSPs lets you build HTML-like documents that interweave snippets of Java code to support dynamic content. At runtime, JSPs are translated to servlet source code, compiled, and then deployed to a Web container dynamically. If you change any part of the JSP, the container detects the change, recompiles the page, and redeploys it. This architecture was called page-driven or Model 1.
In page-driven applications, each page not only contains the business logic required to generate the dynamic content, but also the control logic to determine application flow. Control logic became difficult to maintain because there was no central location or design paradigm to help you understand how a user passed from one page to the next. And as business requirements evolved to include features like authentication and authorization, page code became convoluted with additional logic that usually had to be duplicated across pages, even if it was irrelevant to the page being constructed. On a site with 1,000 pages, all with authorization mechanisms, who wants to update all 1,000 pages when those authorization mechanisms change?
The solution was to separate programmatic responsibilities into the technologies best suited for them. Servlets are great for writing Java code, acting as a central point for managing application flow and invoking business methods, but horrible at presentation; JSPs are great at presentation but are a horrible place to embed all of your business logic. Thus was born the Model 2 architecture, which adheres to the MVC Smalltalk design pattern:
In Java systems, the model is typically a loose JavaBean, or Plain Old Java Object (POJO) that has getters and setters to manipulate its contents. It can be a very simple object or a very complicated one with dozens of subobjects, but it's just an object nonetheless.
The view is usually a JSP page, but countless other technologies and templating languages can be used, such as FreeMarker, Velocity, XML/XSLT, JasperReports, and so on. After the business logic is complete and the model has been generated, the controller passes the model to the view to be presented to the user.
The controller is typically implemented by a servlet that calls into business services to perform some action. The controller usually hosts additional logic such as authentication and authorization: it controls which actions a user can execute. For example, you might not allow a user who hasn't first logged in to post a message to a message board. If the controller notices that the user is trying to access the "post" page, it redirects the user to a login page first.
In a Spring MVC architecture, you implement controllers that make calls into Spring service beans to perform business actions and then send a model object to one of your views for presentation. But I'm getting a bit ahead of myself. First we'll do a quick high-level review of Spring.
During the early days of Enterprise JavaBeans (EJB), developers led by Rod Johnson created the Spring Framework as a lightweight alternative to Java EE's complexity. Spring is many things -- entire books
have been written about it -- but one of the key benefits that it pioneered is dependency injection (DI). DI is a design pattern, coined by Martin Fowler, that separates an application's dependencies (and dependency configuration) from the code that uses those dependencies.
Spring implements DI by allowing you to "wire" together an application from beans, using either an XML configuration file
or annotations. For example, if your application needs to access a database, you can configure your database connection pool
in a Spring configuration file and tell Spring to "inject" a
DataSource from that pool into your data-access object (DAO) bean; then you can inject that DAO into a service bean. The point is that
your application should focus on solving its business problems rather than on the overhead required to construct resources
and objects. Spring creates your objects for you and makes them available at runtime.