http://www.csdn.net/develop/read_article.asp?id=13830
这可是一篇很经典的好文章!
这可是一篇很经典的好文章!
解决方案 »
- javap忽悠了很多人。原来它并不是编译的顺序。
- Which Java collection class can be used to maintain the entries in the order in which they were last accessed?中文什么意思?
- Jframe的setlayout(null)代表什么涵义?
- 在JAVA 中如何用类实现数据联表
- 刚学Java,问一个很初浅的问题
- 这个错误提示是什么意思?
- 自学java,求视频推荐
- 问题帮我解决了,高分给他!!!!!!!!
- 在线等解,急急!!!!!!!!
- statement到底是个什么东西?接口、类,谁能说明白它的原理,100分只给一个人
- 关于Java Mail
- 有谁知道JAVABOOK包是什么啊?
视图:用户界面
控制:用来管理模型和视图之间交互以及应用程序的流程控制。
视图:用户界面
控制:用来管理模型和视图之间交互以及应用程序的流程控制。
Supporting Multiple Enterprise Clients
Now, more than ever, enterprise applications need to support multiple
types of users with multiple types of interfaces. For example, an online
store may require an HTML front for Web customers, a WML front for
wireless customers, a JFC/Swing interface for administrators, and an XMLbased
Web service for suppliers.
When developing an application to support a single type of client, it is sometimes
beneficial to interweave data access logic with interface-specific logic for
presentation and control. Such an approach, however, is inadequate when
applied to enterprise systems that need to support multiple types of clients:
Different applications need to be developed, one to support each type of client
interface.
Non-interface-specific code is duplicated in each application, resulting in
duplicate efforts in implementation (often of the copy-and-paste variety), as well
as testing and maintenance.
The task of determining what to duplicate is expensive in itself, since interfacespecific
and non-interface-specific code are intertwined.
The duplication efforts are inevitably imperfect. Slowly, but surely, applications
that are supposed to provide the same core functionality evolve into different
systems.
How can an enterprise support multiple types of clients and at the same time
avoid these costs? The following forces influence the solution:
The same enterprise data needs to be accessed when presented in different
views: e.g. HTML, WML, JFC/Swing, XML.
The same enterprise data needs to be updated through different interactions: e.g.
link selections on an HTML page or WML card, button clicks on a JFC/Swing
GUI, SOAP messages written in XML.
Supporting multiple types of views and interactions should not impact the
components that provide the core functionality of the enterprise application.
A Solution: Use the Model-View-Controller Architecture
By applying the Model-View-Controller (MVC) architecture to a J2EE
application, you separate core data access functionality from the
presentation and control logic that uses this functionality. Such separation
allows multiple views to share the same enterprise data model, which
makes supporting multiple clients easier to implement, test, and maintain.
The MVC architecture has its roots in Smalltalk, where it was originally applied to
map the traditional input, processing, and output tasks to the graphical user
interaction model. However, it is straightforward to map these concepts into the
domain of multi-tier enterprise applications:
The model represents enterprise data and the business rules that govern access
to and updates of this data. Often the model serves as a software approximation
to a real-world process, so simple real-world modeling techniques apply when
defining the model.
A view renders the contents of a model. It accesses enterprise data through the
model and specifies how that data should be presented. It is the view's
responsibility to maintain consistency in its presentation when the model
changes. This can be achieved by using a push model, where the view registers
itself with the model for change notifications, or a pull model, where the view is
responsible for calling the model when it needs to retrieve the most current data.
A controller translates interactions with the view into actions to be performed by
the model. In a stand-alone GUI client, user interactions could be button clicks or
menu selections, whereas in a Web application, they appear as GET and POST
HTTP requests. The actions performed by the model include activating business
processes or changing the state of the model. Based on the user interactions and
the outcome of the model actions, the controller responds by selecting an
appropriate view.
The MVC architecture has the following benefits:
Multiple views using the same model. The separation of model and view
allows multiple views to use the same enterprise model. Consequently, an
enterprise application's model components are easier to implement, test, and
maintain, since all access to the model goes through these components.
Easier support for new types of clients. To support a new type of client, you
simply write a view and controller for it and wire them into the existing enterprise
model.
Supporting Multiple Enterprise Clients
Now, more than ever, enterprise applications need to support multiple
types of users with multiple types of interfaces. For example, an online
store may require an HTML front for Web customers, a WML front for
wireless customers, a JFC/Swing interface for administrators, and an XMLbased
Web service for suppliers.
When developing an application to support a single type of client, it is sometimes
beneficial to interweave data access logic with interface-specific logic for
presentation and control. Such an approach, however, is inadequate when
applied to enterprise systems that need to support multiple types of clients:
Different applications need to be developed, one to support each type of client
interface.
Non-interface-specific code is duplicated in each application, resulting in
duplicate efforts in implementation (often of the copy-and-paste variety), as well
as testing and maintenance.
and non-interface-specific code are intertwined.
The duplication efforts are inevitably imperfect. Slowly, but surely, applications
that are supposed to provide the same core functionality evolve into different
systems.
How can an enterprise support multiple types of clients and at the same time
avoid these costs? The following forces influence the solution:
The same enterprise data needs to be accessed when presented in different
views: e.g. HTML, WML, JFC/Swing, XML.
The same enterprise data needs to be updated through different interactions: e.g.
link selections on an HTML page or WML card, button clicks on a JFC/Swing
GUI, SOAP messages written in XML.
Supporting multiple types of views and interactions should not impact the
components that provide the core functionality of the enterprise application.
A Solution: Use the Model-View-Controller Architecture
By applying the Model-View-Controller (MVC) architecture to a J2EE
application, you separate core data access functionality from the
presentation and control logic that uses this functionality. Such separation
allows multiple views to share the same enterprise data model, which
makes supporting multiple clients easier to implement, test, and maintain.
The MVC architecture has its roots in Smalltalk, where it was originally applied to
map the traditional input, processing, and output tasks to the graphical user
interaction model. However, it is straightforward to map these concepts into the
domain of multi-tier enterprise applications:
The model represents enterprise data and the business rules that govern access
to and updates of this data. Often the model serves as a software approximation
to a real-world process, so simple real-world modeling techniques apply when
defining the model.
A view renders the contents of a model. It accesses enterprise data through the
model and specifies how that data should be presented. It is the view's
responsibility to maintain consistency in its presentation when the model
changes. This can be achieved by using a push model, where the view registers
itself with the model for change notifications, or a pull model, where the view is
responsible for calling the model when it needs to retrieve the most current data.
A controller translates interactions with the view into actions to be performed by
the model. In a stand-alone GUI client, user interactions could be button clicks or
menu selections, whereas in a Web application, they appear as GET and POST
HTTP requests. The actions performed by the model include activating business
processes or changing the state of the model. Based on the user interactions and
the outcome of the model actions, the controller responds by selecting an
appropriate view.
The MVC architecture has the following benefits:
Multiple views using the same model. The separation of model and view
allows multiple views to use the same enterprise model. Consequently, an
enterprise application's model components are easier to implement, test, and
maintain, since all access to the model goes through these components.
Easier support for new types of clients. To support a new type of client, you
simply write a view and controller for it and wire them into the existing enterprise
model.