Showing posts with label Model. Show all posts
Showing posts with label Model. Show all posts

05 November, 2007

Model View Controller (MVC) Architecture

Overview:

Model-View-Controller architecture is all about dividing application components into three different categories Model, View and the Controller. Components of the MVC architecture have unique responsibility and each component is independent of the other component. Changes in one component will have no or less impact on other component.

Model Components:
In the MVC architecture, model components provide an interface to the data and/or services used by an application. This way, controller components don't unnecessarily embed code for manipulating an application's data. Instead, they communicate with the model components that perform the data access and manipulation. Thus, the model component provides the business logic. Model components come in many different forms and can be as simple as a basic Java bean or as intricate as Enterprise JavaBeans (EJBs) or Web services.

View Components:
View components are used in the MVC architecture to generate the response to the browser. Thus, a view component provides what the user sees. Oftentimes the view components are simple JSPs or HTML pages. However, you can just as easily use WML, a templating engine such as Velocity or FreeMarker, XML with XSLT, or another view technology altogether for this part of the architecture. This is one of the main design advantages of MVC. You can use any view technology that you'd like without impacting the Model (or business) layer of your application.

Controller Components:
At the core of the MVC architecture are the controller components. The Controller is typically a servlet that receives requests for the application and manages the flow of data between the Model layer and the View layer. Thus, it controls the way that the Model and View layers interact. The Controller often uses helper classes for delegating control over specific requests or processes.

04 November, 2007

Struts

Overview:

Although the Model-View-Controller architecture is a powerful means of organizing code, developing such code can be a painstaking process. This is where Struts comes in. Struts is a Web application framework that streamlines the building of Web applications based on the MVC design principles. But what does that mean? Is Struts an MVC Web application that you just add on to or extend? Is Struts just some libraries? Actually, Struts is a little bit of both. Struts provides the foundation, or framework, for building an MVC-oriented application along with libraries and utilities for making MVC development faster and easier.
You could create a new Controller servlet every time you wanted to use the MVC design pattern in your Web application. Additionally, you'd need to create the management/flow logic for getting data to and from the Model and then routing requests to the View. You'd also need to define interfaces for interacting with your Model objects and all the utility code that goes along with using the MVC design pattern. However, instead of going through this process each time you create a new application, you can use Struts. Struts provides the basic structure and outline for building that application, freeing you to concentrate on building the business logic in the application and not the "plumbing."
To better understand the benefits of Struts, consider the following analogy. If you were to create a GUI application in Java, you wouldn't write a text field widget and a drop-down widget yourself. You would use Java's Swing API that already has standardized, fully functional code that provides these controls. Not only are the Swing controls ready-to-use, but they are also understood by all Java programmers. Struts provides the same type of advantages: Struts supplies a standard way of implementing an MVC application, the Struts code is tried and true, and the techniques required to use Struts are well known and documented.
In addition to providing the foundation for MVC applications, Struts provides rich extension points so that your application can be customized as you see fit. This extensibility has led to several third-party extensions being made available for Struts, such as libraries for handling application workflow, libraries for working with view technologies other than JSP, and so on.

The Evolution of Struts:

Struts was originally created by Craig R. McClanahan and then donated to the Jakarta project of the Apache Software Foundation (ASF) in May 2000. In June 2001, Struts 1.0 was released. Since then, many people have contributed both source code and documentation to the project and Struts has become the de facto standard for building Web applications in Java and has been embraced throughout the Java community. Struts 1.1 was released in June 2003 and included a substantial amount of new functionality, including the addition of Tiles, Validator, declarative exception handling, and much more. Later, in December 2004, Struts 1.2 was released with several minor updates to the framework. Struts 1.3, released in 2006, introduced the largest change to the framework since the 1.1 release: the move to a chain of responsibility (COR)-based request processing engine.
Today, Struts is continuing to evolve. There are now two distinct major versions of Struts: Struts 1 and Struts 2. Struts 1 is the mature, widely adopted, documented, and supported version of Struts. It is the version of Struts in use now. Struts 2 is a completely new version of Struts based on the merger of Struts and WebWork, another popular open source Java Web application framework. At the time of this writing, Struts 2 is under development and does not have a specific release date. Going forward, Struts 1 and Struts 2 will both be actively developed and maintained as separate subprojects of the Struts project.
Another event has punctuated Struts' evolution: its graduation to a top-level Apache project. Struts is no longer a subproject of the Jakarta Project. This is an important change because it affords Struts more autonomy and gives it the ability to have its own subprojects.