mvc(model-view-controller).txt

一些关于UML的经典讨论

1: 1108002 : ----------------------------------
*原文*(*jdev*于2001/07/31 14:00粘贴) *MVC(Model-View-Controller) *
---------------------------------------------------------------------------
看了很多大家对OOP方面的见解，觉得很多问题其实归结到了MVC(Model-View-Controller). 先看一些Sun对MVC
Architecture是怎么说的：
"
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.
"
简单地来说，Model就是实际的data,大多数情况下存储在database中;View是最终用户端(Client
Side)显示给用户的各种信息，而Controller就是实现Model和View交互的过程。
如果深刻理解了MVC的概念，很多问题就可以得到解决。如实体类和控制类的问题，实体类就是data,通常映射到database中一个或几个相互关联的
table,控制类就是操纵这些data(Model)的具体函数，最终的结果(View)就是要现实的结果，如果没有客户端，那就是根据busines
s logic来确定要达到的结果。
在系统设计和实施时，通常要实现这些目标：
[Code and design reuse] - 代码和设计重复利用
Code reuse decreases the cost for new development, provides incremental
quality improvements (as software flaws are repaired in long-lived
components), and establishes design best practices that everyone in the
organization understands.
[Rational functional decomposition] - 相关功能分解
Every class in the design plays a clearly-defined role in the
application. The resulting design clarity facilitates maintenance,
impact analysis, and system extension; and flattens the learning curve
for new developers.
[Development tasks isolated by skill sets] - 通过技能划分开发目标
The design partitions the application into chunks that reflect the skill
sets of subteams in a development group.
[Decouple classes with differing rates of change] - 根据变化程度决定联系的紧密
Parts of the application that change quickly require both greater ease
of change and looser coupling to the rest of the system. Subsystems that
change more slowly can be more tightly coupled, providing efficiency
opportunities.
[Extensibility] - 可扩展性
Application functionality must be able to keep up with organizational
growth and technological change.
[Modularity] - 模块化
Breaking a design into modules that interact through well-defined
interfaces allows developers to work independently, enhances
maintainability and testability, and provides opportunities for using
purchased components and outsourcing some development.
[Security] - 安全性
Since the application is performing financial transactions, and for the
privacy and security of customers, data security enforcement is crucial.
[Common look-and-feel] - 所想即所得
Applications are easier to use if the user can always guess where to
look for desired information.
[Minimize network traffic] - 减少网络流量
The application should avoid transmitting data needlessly or
redundantly.
[Allow for multiple user interfaces] - 允许多种用户界面
Data should represented in a way most appropriate for the task at hand.
New types of user interfaces should be easy to add.
[Persistent data must always be consistent] - 永久性数据的完整性
MVC的最直接的运用就是现在的Web Application.Front End(View)是不同类型的用户界面，如Web
Browser(HTML, WML格式)或客户端应用程序,是View;Back End(Model)就是和Business
Logic密切相关的data,通常情况下mapping到一个或多个数据库的table;其他的就是Controller.在具体一点，通过Entit
y
Bean实现了实体数据和对象的映射，通过JSP,HTML页面实现了客户端的不同的View,Servet或CGI解决了如何根据不同的要求对相同的数
据达到不同的显示效果，控制数据间的约束关系，根据实际的要求操纵数据。
对于一个系统的设计，要考虑系统要实现什么功能，体现怎样的View;系统中涉及到什么数据，数据间有什么具体的关系，如何将这些数据保存，如何保证数据
的完整性(data
integrity);如何根据系统设计的要求确定系统流程，即程序流程。将MVC的思想应用到系统的设计和开发过程中，会大大节省系统开发和维护的时间
和精力。
MVC Architecture是当前IT业界最为流行的系统开发方式。在此基础上派生出更多其它的模式(Pattern).
// jdev
---------------------------------------------------------------------------


2: 1108073 : ----------------------------------
*原文*(*gt7092b*于2001/08/01 05:17粘贴) *overrated MVC *
---------------------------------------------------------------------------
Personally, I found MVC was overrated. Conceptually it's a good idea to
decouple two related abstractions (Model and View) by using a
middleman(Controller). However, I found MVC had shortcomings when
applied to large-scale and/or web projects.
Large-scale projects usually have layered architecture. Model most
likely stays at lower layer close to database, whereas view stays at
higher layer close to clients. Updating model through controller
requires either penetrating through different layers, most likely across
network or providing a model proxy at higher layer and trying hard to
keep the proxy in sync with model itself. It could be even worse when
incremental updates get involved. Also, think about how many controllers
do you need for your project? one per model or one for all models?
I appreciate the insight brought in by MVC pattern, but I will be
careful about using it. My feeling is if you have an architecture where
your views are very close to models, then use it. If not, reconsider it
since the purpose of the pattern is not to have the couple come too
close. Is it right?
Another feeling about this pattern is whether model equals data. I think
not. I think model could also be non-persistent entities as well. It
could also be processed database schema. I will think it as abstract
data that views relying on. Maybe swing TableModel reminds us something.
In a distribute environment, sometimes it's really hard to say where the
model is. Tying model to data itself probably will hurt your system's
performance.
That's my humble opinion.
---------------------------------------------------------------------------


3: 1108079 : ----------------------------------
*原文*(*walaqi*于2001/08/01 09:22粘贴) *k,为什么不用中文？ *
---------------------------------------------------------------------------

---------------------------------------------------------------------------


4: 1108081 : ----------------------------------
*原文*(*loveuml*于2001/08/01 09:25粘贴)
*你笨啊！没看见人家的发贴时间，就知道和你不在一个半球上了 *
---------------------------------------------------------------------------
打中文不方便
---------------------------------------------------------------------------


3: 1108078 : ----------------------------------
*原文*(*bobgeng*于2001/08/01 09:21粘贴) *回复: overrated MVC *
---------------------------------------------------------------------------
I agree with you by and large.
Just like what you said, MVC was overrated. I had emplemented a
framework of a simple web application adopted MVC technique. Besides I
used event-driven into my design. So I got the architecture of
Viewer(based on web and console),Event Driver on client; Event
Driver,Business Logic Controller and Modeler on server. Although Event
Driver contacts only with Business Logic Controller who encapsulated the
data Model, I had to implemented the Model controller as DAO(Data Access
Object) for every Model worked as persistent object. It's a lot of
work,and tedious in fact.
You opinion about relationship of model and data is terrific. Sometimes
(and almost every large-scale project) models for abstract data are
neccessary. Just like what had been done in petStore,a J2EE sample
project.
Although MVC was overrated, it's still a great idea for your project's
framework.
---------------------------------------------------------------------------


4: 1108091 : ----------------------------------
*原文*(*dean fang*于2001/08/01 11:03粘贴) *think about COM+ *
---------------------------------------------------------------------------
I don't familiar with Appllication server for Java such as
Weblogic,Websphere.but I have expierence in MS COM+.And I agree that MVC
pattern(in RUP it's Entity,Boundary and Controller) do not meet large
scalble project or n-tier project well,at least you must make some
adjustments.
I remember that the "conflict" bewteen COM+ and OO has been discussed
here before.If you have interest in this,you may search keyword "COM+ Vs
OO".
---------------------------------------------------------------------------