At a simple level, the components of MVC architecture interact as shown below. The Model holds the data, the View retrieves the data and generates a dynamic display, and the Controller provides the logic processing layer and delegation to the Model and View:
The Model represents the business logic of an application. Encapsulating business rules into components facilitates testing, improves quality, and promotes reuse.
The Model can be further partitioned into State and Action components.
State Components
The State defines the current set of values of the Model and includes methods to change those values. These methods are where some of the business logic is captured.
Note: The State components are usually protocol independent. JavaBeans are a logical choice for implementing the State components.
The reusable nature of beans allows for the somewhat independent construction of the State components. As far as being protocol independent, State components should be isolated enough so they can be accessed by applications that use HTTP, RMI, etc., that is, the protocol would be another layer on top of the component. Their construction should take into account current requirements and consider future growth and evolution. This independent construction facilitates sound design in these ways:- Reuse Elimination of presentation logic allows different applications (for different audiences or using different technology) to make use of the same business logic.
- Quality By putting the business logic in one place, it can be reviewed and tested more thoroughly. Contrast this approach with the cost and less stringent test coverage if the business logic were embedded in each application that needs it.
- Robustness The business logic is more easily enforced. Encapsulating the logic in one place can encourage its reuse, reducing room for errors to creep into the logic. For example, if every designer of a series of related applications (say time entry, expense reports, project budget requests, and salary planning) used the same Approval bean to route cost-related items (such as a time sheet charges to project budgets, expense reports for business trips, funding requests for pilot projects, and raise requests), the same business logic would be enforced across the entire suite of applications.
The Actions define the allowable changes to the State in response to events. Business logic also dictates the construction of Action components.
In implementing the Action components, the choices get more complex. In simple systems, the Actions may actually get absorbed into the Controller, but this is generally not recommended. Typically a layer of Action beans is created to capture the requirements that govern interaction with the State components. As far as our time entry system, the 'Summary' action represents an example of an Action component.
Often Action components must be aware of the protocol in order to obtain information about the event. This is a dangerous situation, as it ties business logic to a specific protocol, limiting potential reuse.
Some simple rules of thumb are helpful when constructing your Action components. Adapt and add to this list for your particular set of requirements:
- Take a passive approach to Action components, only handling what each absolutely needs to handle. Create more State components if you need them. The Controller will manage all events and invoke the appropriate calls to Action methods.
- Partition the business logic to keep it separate from the implementation protocol (ideally in separate beans). As this book is focused on the HTTP browser based protocols, consider partitioning the use of resources from javax.servlet.* and javax.servlet.http.* packages into a separate layer from business rules (say, via an adapter design pattern). This allows the business rules to be reused in other architectures such as a GUI based and non- servlet architectures such as RMI or CORBA.
The View represents the presentation logic of an application. The View components obtain the current state of the system from the Model and provide the user interface for the specific protocol involved. For the focus of this book, the protocol we are interested in is HTTP browser based systems.
As part of the generation of the user interface, the View is responsible for presenting the specific set of events that the user may enact at any given moment.
Note: Separating the View from the Model enables the independent construction of user interfaces with different look and feel attributes. These different interfaces can all interact with the same Model. JSPs are a natural choice for implementing the View.
As we have seen, JSPs are a convenient choice for generating HTTP browser based user interfaces. Interaction with the Model (beans) is easy via the built-in beans tags.
Will be continued soon.....
