JSP model 1 architecture: Difference between revisions
m Bot: Migrating 1 interwiki links, now provided by Wikidata on d:q6888170 |
Undid revision 527530884 by 129.184.84.11 (talk) rvv |
||
| Line 2: | Line 2: | ||
In the design of [[Java (programming language)|Java]] [[Web application]]s, there are two commonly used design models, referred to as '''Model 1''' and [[Model 2]].<ref>[http://www.kirkdorffer.com/jspspecs/jsp092.html#model JavaServer Pages - Specification 0.92. JavaServer Pages Access Model. October 7, 1998]</ref> |
In the design of [[Java (programming language)|Java]] [[Web application]]s, there are two commonly used design models, referred to as '''Model 1''' and [[Model 2]].<ref>[http://www.kirkdorffer.com/jspspecs/jsp092.html#model JavaServer Pages - Specification 0.92. JavaServer Pages Access Model. October 7, 1998]</ref> |
||
[[File:Model 1.png|thumb|upright=1.75|alt=A diagram of a Model 2 implementation.|A simplified diagram of a Model 1 implementation.]] |
[[File:Model 1.png|thumb|upright=1.75|alt=A diagram of a Model 2 implementation.|A simplified diagram of a Model 1 implementation.]] |
||
In Model 1, a request is made to a [[ |
In Model 1, a request is made to a [[JavaServer Pages|JSP]] or [[servlet]] and then that JSP or servlet handles all responsibilities for the request, including processing the request, validating data, handling the business logic, and generating a response. The Model 1 architecture is commonly used in smaller, simple task applications due to its ease of development. |
||
Although conceptually simple, this architecture is not conducive to large-scale application development because, inevitably, a great deal of functionality is duplicated in each JSP. Also, the Model 1 architecture unnecessarily ties together the business logic and presentation logic of the application. Combining business logic with presentation logic makes it hard to introduce a new 'view' or access point in an application. For example, in addition to an [[HTML]] interface, you might want to include a [[Wireless Markup Language]] (WML) interface for wireless access. In this case, using Model 1 will unnecessarily require the duplication of the business logic with each instance of the presentation code. |
Although conceptually simple, this architecture is not conducive to large-scale application development because, inevitably, a great deal of functionality is duplicated in each JSP. Also, the Model 1 architecture unnecessarily ties together the business logic and presentation logic of the application. Combining business logic with presentation logic makes it hard to introduce a new 'view' or access point in an application. For example, in addition to an [[HTML]] interface, you might want to include a [[Wireless Markup Language]] (WML) interface for wireless access. In this case, using Model 1 will unnecessarily require the duplication of the business logic with each instance of the presentation code. |
||
Revision as of 19:28, 2 July 2013
In the design of Java Web applications, there are two commonly used design models, referred to as Model 1 and Model 2.[1]
In Model 1, a request is made to a JSP or servlet and then that JSP or servlet handles all responsibilities for the request, including processing the request, validating data, handling the business logic, and generating a response. The Model 1 architecture is commonly used in smaller, simple task applications due to its ease of development.
Although conceptually simple, this architecture is not conducive to large-scale application development because, inevitably, a great deal of functionality is duplicated in each JSP. Also, the Model 1 architecture unnecessarily ties together the business logic and presentation logic of the application. Combining business logic with presentation logic makes it hard to introduce a new 'view' or access point in an application. For example, in addition to an HTML interface, you might want to include a Wireless Markup Language (WML) interface for wireless access. In this case, using Model 1 will unnecessarily require the duplication of the business logic with each instance of the presentation code.