Question

对MVC模式的理解是什么？

Answer 1

对MVC模式的理解是什么？, 描述一下对MVC模式的理解？
Model（模型）表示应用程式核心（比如资料库记录列表）。
View（检视）显示资料（资料库记录）。
Controller（控制器）处理输入（写入资料库记录）。
下面说说简单的理解,个人感觉:
Model 实体类,例如蛋糕,奶茶,糖果
View 介面控制,例如店面
Controller 使用者介面类,使用者会首先访问这个东西,例如营业员
上面三者合起来就是 你构建了一个场景:营业员在经营食品店....然后你的客户访问你的网页就像去买糖果一样
另外,这模式就是一种划分而已,尤其是实体类多和业务逻辑复杂,中大型专案建议使用
用比较老的开发方法就是没划的这么清晰,但是小专案比MVC更方便
谈谈对MVC和Struts模式的理解
MVC方式通常在Smalltalk中用于建立使用者介面。通过对MVC中蕴藏的设计模式可以帮你理解我们所说的“模式”的含义。
MVC包括三类物件，Model是应用物件、View为其萤幕表示、Controller定义了对使用者输入的处理（反应）方式。在应用MVC方式以前，通常将这三个物件的功能合到了一起，应用MVC分离了它们，为设计提供了灵活性和可重用性。
MVC通过在view和model之间建立Subscribe/Notify协议，分离了view和model物件。View物件必须保证它的表示反应了model物件的状态，当model物件的资料改变时，model物件通知（Notify）view物件，作为对这一行为的反应，每个view物件得到了一个做出更新的机会。这种方式使得可以将多个view物件为一个model物件提供不同的表示。你也可以为model物件建立新的view物件，而不用重新编写model。下图演示了一个model和三个view：
从表面看，这一例子反应了一个将view和model分离的设计。然而，这种设计适合一类更通用的问题：减少物件之间的藕和性，这样，当一个物件改变时，将不会影响到另外的物件，甚至不需要知道另外的物件的实现细节。这种更通用的模式将在Observer模式中来描述。
MVC方式的另一个特点是，view物件是可巢状定义的。例如，button的控制板可由一个包含巢状button view物件的复杂view物件来实现；物件观察器的使用者介面可由能重用于侦错程式的巢状view物件组成。MVC方式采用CompositeView类（View的子类）来支援巢状view，其行为与view物件的行为一致，可用于view物件能使用的任何场合。
于是，我们又可以把这种对待posite view就像处理其一个元件的方式看成一种设计（方式）。同样的，这种设计可抽象出另一类更通用的问题（的解决方式）：我们在某种情形下将物件分成组，并且处理一个组就像对待物件个体。这种方式我们用Composite设计模式来描述。它允许你建立类的层次，在这一层次下，有些子类定义原始物件（如Button），而其它的类可以定义合成物件（CompositeView），合成物件可将原始物件装配成更复杂的物件。
同样，MVC也可改变检视类（view）对使用者反应的方式，而不用改变其视觉化表示。你可能想改变其对键盘响应的方式，如，使用弹出选单代替命令键。MVC将这种反应机制封装为控制物件（Controller）。控制器有一个类层次，易于实现从一个已存在的控制器建立出一个变种—一种新的控制器。
检视（view）物件通过某一控制器物件的例项（instance）来实现特定的响应策略。为了实现不同的策略，可以简单的使用不同的控制器例项来替换当前的例项。甚至可以在执行时来改变检视的控制器，以改变检视物件对使用者输入的响应（策略）。例如，一个view物件可置为disabled，即对使用者的输入不做任何响应。要达到这一目的，仅仅只需让控制器忽略所有input事件。
这种检视—控制器关系即是Strategy设计模式的一个典型例子。所谓Strategy即这样一个物件，它表示了一种演算法。这在你想要替换演算法（无论是静态替换还是动态替换）时特别有用，而这样的演算法可能有许多的变数、或者拥有复杂的资料结构。
MVC中也使用了别的设计模式，例如，使用Factory Method模式来描述检视的预设控制器类；采用Decorator模式来为检视增加滚动条等。但在MVC中的主要模式是前述的Observer、Composite、和Strategy设计模式。
如何理解spring MVC模式
1. 原理
Spring MVC按植物分类学属于Martin Flower〈企业应用模式〉里的静态配置型Front Controler，使用DispatchServlet截获所有*.do的请求，按照xml档案的配置，呼叫对应的Command物件的 handleRequest(request,response)函式，同时进行依赖物件的注入。
我们的Controller层，就是实现handleRequest(request,response)函式的普通JavaBean。
2. 优势
Spring MVC与struts相比的优势:
一是它的Controller有着从松到紧的类层次结构，使用者可以选择实现只有一个HandleRequest()函式的介面，也可以使用它有很多回调函式的SimpleFormController类。
二是不需要Form Bean，也不需要Tapestry那所谓面向物件的页面物件，对于深怕类膨胀，改一个东西要动N个地方的人最适合不过。
三是不需要强XML配置档案，宣告式程式设计是好的，但如果强制成框架，什么都要在xml里面宣告，写的时候繁琐，看的时候也要程式码配置两边看才能明白就比较麻烦了。

那Webwork呢?没有实战过，不过因为对MVC框架所求就不多，单用Spring MVC的Controller已经可以满足需求，就不多搞一套Webwork来给团队设坎，还有给日后维护，spring,ww2之间的版本升级添麻烦了。真有什么需要新增的，Spring MVC原始码量很少，很容易掌控和扩充套件。

3.化简
3.1. 直接implement Controller，实现handleRequest()函式
首先，simple form controller非我所好，一点都不simple。所以有时我会直接implement Controller介面。这个介面的唯一函式是供Front Controller呼叫的handleRequest(request,response)。
如果需要application物件，比如想用application.getRealPath()时，就要extends webApplicationObjectSupport。
3.2.每个Controler负责一组相关的action
我是坚决支援一个Controler负责多个action的，一个Controler一个action就像一个function一个类一样无聊。所以我用最传统的方式，用URL引数如msg="insert"把一组相关action交给一个Controler控制。ROR与制作中的Groovy On Rails都是这种模式，Spring也有MultiActionController支援。
以上三者都是把URL引数直接反射为Controller的函式，而Stripes的设计可用annotation标注url action到响应函式的对映。
3.3.xml宣告式程式设计的取舍
我的取舍很简单，反正Spring没有任何强制，我只在可能需要不重新编译而改变某些东西的时候，才把东西放在xml里动态注入。jsp路径之类的就统统收回到controller里面定义.
如何理解mvc模式中的model
MVC(Model/View/Controller)模式是国外用得比较多的一种设计模式，好象最早是在Smaltalk中出现。MVC包括三类物件。Model是应用物件，View是它在萤幕上的表示，Controller定义使用者介面对使用者输入的响应方式。
模型-检视-控制器（MVC）是80年代Smalltalk-80出现的一种软体设计模式，现在已经被广泛的使用。
1、模型（Model）
模型是应用程式的主体部分。模型表示业务资料，或者业务逻辑.
2、检视（View）
检视是应用程式中使用者介面相关的部分，是使用者看到并与之互动的介面。
3、控制器（controller)
控制器工作就是根据使用者的输入，控制使用者介面资料显示和更新model物件状态。
MVC 式的出现不仅实现了功能模组和显示模组的分离，同时它还提高了应用系统的可维护性、可扩充套件性、可移植性和元件的可复用性
早期的程式中，如果不注意对数功能和显示的解耦合，常常会导致程式的复杂及难以维护。很多VB,Delphi等RAD程式都有这种问题。甚至现在的C#,Java有时候也会出现把业务逻辑写在显示模组中的现象
管MVC设计模式很早就提出，但在Web专案的开发中引入MVC却是步履维艰。主要原因：一是在早期的Web专案的开发中，程式语言和HTML的分离一直难以实现。CGI程式以字串输出的形式动态地生成HTML内容。后来随着指令码语言的出现，前面的方式又被倒了过来，改成将指令码语言书写的程式嵌入在HTML内容中。这两种方式有一个相同的不足之处即它们总是无法将程式语言和HTML分离。二是指令码语言的功能相对较弱，缺乏支援MVC设计模式的一些必要的技术基础。直到基于J2EE的JSP Model 2问世时才得以改观。它用JSP技术实现检视的功能，用Servlet技术实现控制器的功能，用JavaBean技术实现模型的功能
JSP Model 1 与 JSP Model 2
SUN在JSP出现早期制定了两种规范，称为Model1和Model2。虽然Model2在一定程度上实现了MVC，但是它的应用用并不尽如人意
JSP Model 1
JSP Model 2
model2 容易使系统出现多个Controller，并且对页面导航的处理比较复杂
有些人觉得model2仍不够好，于是Craig R. McClanahan 2000年5月提交了一个WEB framework给Java Community.这就是后来的Struts.
2001年7月，Struts1.0，正式释出。该专案也成为了Apache Jakarta的子专案之一
Struts 质上就是在Model2的基础上实现的一个MVC架构。它只有一个中心控制器，他采用XML定制转向的URL。采用Action来处理逻辑
理解阐述 MVC模式 优势在哪
MVC思想将一个应用分成三个基本部分：Model（模型）、View（检视）和Controller（控制器），这三个部分以最少的耦合协同工作，从而提高应用的可扩充套件性及可维护性。
MVC模式与三层模式的区别?
晕，居然还有人说是一个意思
你所指的三层是j2ee设计中的三层，这个你很清楚，我就不说了。
MVC是java设计模式中的术语，跟这个三层说的不是一个方面的东西。
MVC ：model，view，control 表示，如果软体需要用到UI介面，那么就应该分成： 模型层，表示层，控制层三层，
原因是模型表示资料原形， 表示层用来对资料进行绘制和表示。控制用来操控这些资料，
使用者一般看到了表示层上的介面，使用控制层来控制介面，最后的结果影响到模型层。
MVC模式与工厂模式，单例模式，命令模式，等等一起共20多种合称为程式语言的设计模式，它是我们平时程式设计时的经验累积。我们在设计我们的程式时可以以它们做为参考进行程式的架框设计。
最后再说一句： MVC的要义就是显示的专业显示，逻辑的专业逻辑， 逻辑与绘图分开，不一定会是三层，可能会有更多层。只要能达到MVC要求的规则，你想几层都可以。 目的就是达到程式的各个模组之间尽量脱藕合。
可能我们说得让你有点一头雾水，所以强烈建议楼主去补习一下20多种设计模式。学了设计模式会对你的程式水平有质的提升，真的，我就是学完会爱上java的，以前把学习java当成任务，但学了设计模式后就爱上它了!
为什么要使用MVC模式，MVC模式的优势有哪些
最大的优势在于mvc可以利于维护，以前java程式码和前端程式码混在一起，很不容易维护
如何理解MVC模式还有工厂设计模式
1、MVC属于框架模式，框架与设计模式虽然相似，但却有着根本的不同。设计模式是对在某种环境中反复出现的问题以及解决该问题的方案的描述，它比框架更抽象；
2、框架可以用程式码表示，也能直接执行或复用，而对模式而言只有例项才能用程式码表示;设计模式是比框架更小的元素，一个框架中往往含有一个或多个设计模式，框架总是针对某一特定应用领域，但同一模式却可适用于各种应用。
3、可以说，框架是软体，而设计模式是软体的知识。
android和ios的mvc模式的区别
在学习 iOS 应用程式开发时，需对Cocoa Touch 的几种设计模式有所了解。 谈到设计模式，有人会觉得这是纸上谈兵，故作玄虚。我们这里不谈设计模式有多么多么神奇， 只对iOS Framework 已经用到的设计模式，逐一剖析。
学习iOS 开发，以下几种设计模式，是不可不知的：
Target Action Design Pattern;
Notification Pattern
MVC Pattern
KVO （Key-Value Observing）
Singleton Pattern
Delegate Pattern

MVC 设计模式
相信你对 MVC 设计模式 并不陌生。从字面意思来理解， Modal , View , Controller ，其用意在于将资料与检视分离开来。 在iOS cocoa touch 程式设计中， MVC机制被发挥得淋漓尽致。 MVC 示意图如下。 只有充分理解了MVC，才能在编写出优雅的iOS app。为充分理解 MVC， 相关的概念（比如： Delegate、 Protocol、 Notification 等）也要了然于胸。
MVC 约定， Model 不允许与View 打交道。 Model 是管理资料的， 当Model中的资料发生变化时，与之对应的检视应更新。 这就需要一种机制来支援。为此 iOS 框架提供了两种支援机制： Notification 和KVO （Key-Value Observing）。 KVO 可简单理解为，为你所关注的 Key 物件注册一个监听器。 当有资料发生变化时，就会发出广播给所有的监听器。
MVC 也约定， View 不允许直接引用Modal， 它只能被Controller 所控制。 Controller 控制 View 显示什么资料。我们知道，View 所要显示的资料是来源于 Modal， View 上产生的事件 （ 比如 Touch事件）需要通知 Controller。 既然MVC 不允许直接打交道，就需要提供一种机制。
不错， iOS 确实提供了一种机制， 名曰： Delegate。 Delegate 这个词， 有人将它译为“委托”，也有人将它译为“代理”。名称上的差异没有什么，重要的是如何理解 Delegate。 Delegate设计模式的引入，就是为了解决UIView与Controller松耦合互动问题。
为便于理解， 这里撷取一张来iOS MVC 示意图：
我们在详细介绍下这张图的内涵：
1. 图中，绿色的箭头表示直接引用。 对View 的直接引用体现在 IBOutlet 上。 当引用一个View 时，比如Button。 需要在ViewController
中宣告一个 IBOutlet UIButton * btn；
2. 然后，我们看View 是怎么向 Controller 通讯的。对于这个， iOS 有三种常见的模式：
设定View对应的Action Target。如设定UIButton的Touch up inside的Action Target。
设定View的Delegate，如UIAlertViewDelegate, UIActionSheetDelegate，UITextFieldDelegate等。
设定View的data source, 如UITableViewDataSource。
通过以上三种模式，View既能向Controller通讯，又无需知道具体的Controller是谁，这样，View 就与Controller解耦了。
除此之外， iOS 还提供了 Action-Target 模式来让Controller 监听View 触发的事件。 View 又是如何获取资料呢？ iOS提供了 Data source 的概念，其实也就是Protocol 的应用。
综上所述， 正是在iOS MVC框架的驱使下， 才需要深入理解 Delegate、Protocol等概念。