Summary

In this chapter we've looked at why it's crucial to separate presentation from control logic in web interfaces, and why it's equally important that a web interface is a thin layer built on well-defined business interfaces.

We've looked at the many shortcomings of naÏve web application architectures such as the "JSP Model 1" architecture, in which JSP pages are used to handle requests. We've seen that Java objects are the correct choice for handling control flow in web applications, and that JSP is best used only as a view technology.

We've looked at how the MVC architectural pattern (also known as "Model 2" or "Front Controller" architecture) can help to achieve our design goals for web applications. We've seen the importance of decoupling controller components (which handle control flow in the web tier) from model components (which contain the data to display) and view components (which display that data). Such decoupling has many benefits. For example, it enables us to use domain objects as models, without necessarily creating web-specific models. It ensures that presentation can easily be changed without affecting control flow: an important way to minimize the likelihood of functional bugs being introduced when a site's presentation changes. It achieves a clear separation of the roles of Java developer and presentation developer - an essential in large web applications. We saw that complete "view substitutability" (the ability to substitute one view for another displaying the same data model without modifying controller or model code) is the ideal level of decoupling between controller and view components. If we achieve this (and it is achievable, with good design), we can even switch view technology without impacting on control flow.

We've examined three open source MVC frameworks (Struts, Maverick, and WebWork), and seen how real MVC implementations share many common concepts. We've examined the design of the MVC framework used in the sample application, which combines some of the best features of the three. This framework is intended for use in real applications, and not merely as a demonstration. It is built on the JavaBean-based infrastructure we discussed in the last chapter, which makes it easy to configure and makes it easy for web-tier components to access application business objects without depending on their concrete classes.

We looked at the problem of web-tier state management. We looked at strategies to ensure that applications maintaining stateful web-tiers are scalable, and considered the alternatives of holding session state in the client browser and in hidden form fields.

We looked at the problem of data binding in web applications (the population of Java object properties from request parameter values), and how web application frameworks address the problem of form submission and validation.

Finally, we looked at the design and implementation of the web tier in the sample application, showing how it meets the design goals we set ourselves for the web tier.

So far we've paid little attention to view technologies such as JSP or XSLT. In the next chapter we'll look more closely at web-tier views, and how we can display model data when using an MVC approach.



Expert One-on-One J2EE Design and Development
Microsoft Office PowerPoint 2007 On Demand
ISBN: B0085SG5O4
EAN: 2147483647
Year: 2005
Pages: 183

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net