By: Barbara Viewed: 153194 times
The Model 1 architecture has one thing going for it: simplicity. If your project is small, simple, and self-contained, it's the quickest way to get up and running. But the previous example, although by no means large or complicated, already illustrates a number of the disadvantages of Model 1 architecture:
It becomes very hard to change the structure of such Web applications because the pages are tightly coupled. They have to be aware of each other. What if you decide that, after updating the quantities in a shopping cart, you want to redirect the user back to the catalog? This could require moving code from the shopping cart page to the catalog page.
Large projects often involve teams of programmers working on different pages, and in the Model 1 scenario, each team would have to have a detailed understanding of the pages on which all of the other teams were working; otherwise, modifying pages could break the flow of the application.
Pages that are linked to from many other pages have to handle those other pages' logic, such as a cart update. In this way, they can accumulate a large amount of code that hasn't got an awful lot to do with the page itself. This reduces their coherence, making them harder to understand and to maintain.
Presentation and application control logic are mixed up, making it hard for a Web designer to change the pages without messing up the Java code. And vice versa: it's very hard for a developer to change control logic that may be hidden in lots of HTML markup.
The lack of separation between presentation and logic means that providing multiple presentations carries a very high cost. What if you decide to sell pizzas via Wireless Application Protocol (WAP) or personal digital assistant (PDA) devices? These devices are radically different from Web browsers and require completely different presentation structure and formatting. Your only choice would be to produce a whole new set of pages and duplicate the application logic. You'd have to implement every subsequent change to the logic in more than one place. Soon enough, changes will become very hard to manage, and the implementations will start to diverge.
Of course, the obvious way to get around these problems is to separate out the presentation code from the application control logic. This leads you onto the next architecture, JSP Model 2 architecture.
Most Viewed Articles (in JSP )
Latest Articles (in JSP)
Comment on this tutorial
- Cloud Computing
- Java Beans
- Mac OS X
- Office 365
- Tech Reviews
Subscribe to Tutorials
1. Good explanation with simple language and style. N
View Tutorial By: Ismail. MC at 2009-03-31 04:46:04
2. ya....good Explanation...very useful and easily un
View Tutorial By: Navya at 2010-09-27 01:28:27