请问JAVA中的MVC(model-view-controller)与mfc中的Document-View是否是一个概念？ mvc具体是javabean-jsp-serveletmfc的搞不清楚 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 Java里mvc不是javabean-jsp-servletJava的MVC组织方式和MFC原理差不多，实现上有点差别。是Model+Observable+Observer模式关键是思想没变，所以很容易从MFC过来比MFC容易10倍！决不夸张。MFC我用了两年，也没成高手我用了半年就很熟悉Java的类库了（不过VC/MFC对我理解Java很有帮助） MVC其实是模、视图、控制的缩写，也就是说在使用jsp时，有相应的文件去实现相应的操作。通常jsp只负责view也就是只负责显示页面。业务逻辑等有bean(ejb)去实现，C通常会由servlet去实现，或者使用struts。struts的介绍你可去http://jakarta.apache.org/struts mvc是一个经典的design patternmfc那套document-view，有点model+viewer的意思，不过一点也不优雅。mfc真的很烂，很晦涩。 牛头不对马嘴MFC是程序框架，是在Windows下开发应用程序的框架，是根据Windows下应用程序开发的一些问题和特点总结归纳并形成的一些类的框架。要勉强拿来和awt什么的相比，还能说得过去。MVC要理解不妨从 Multi-tier 多层结构的开发模式角度来理解。它强调的是java提供的多种技术手段解决各自层面的问题，因此组合使用这些技术手段的方式就能影响到你的开发方式和思路。好比MVC把软件开发抽象成为 逻辑模块、视图、控制，对应就是用Beans来封装系统提供的底层功能模块，用JSP主要处理页面输出相关的东西--也就是表现层。另外还需要一些jsp程序或者servlet来实现控制--也就是你的软件系统提供的应用逻辑--比如用户登录该调用哪个bean，该用哪个jsp返回什么信息给用户。在系统设计人员的眼里来看，他把自己要开发的系统设计成为MVC这样的一个结构，并用java相应的技术去体现这样的层次结构。如果你要用微软的技术体系，同样的多层结构按我所喜欢的方式来做就是：经过仔细封装的数据库存储过程和基于ATL开发COM/COM+组件、进行应用逻辑控制的组件（允许用VB）或ASP Class/ASP、仅仅处理表现层的ASP。在具体的模块中可以采用一定的设计模式，比如用存储过程来封装提供给COM组件的数据库存取层的逻辑，用class 来封装COM提供给asp的一些方法，就好比proxy那样提供给表现层的asp程序。显然，设计模式和MVC不是一个层面上的东西。这里关心的主要是如何把表现层的东西和应用逻辑以及系统底层模块分开，struct这一类的问题重点都是考虑如何在开发人员和他们的工作之间也能分出层次，并如何有效协作。显然这和MFC的Document-View技术不是一个层次的问题。牛头不知道哪里去了？ “MFC是程序框架，是在Windows下开发应用程序的框架，是根据Windows下应用程序开发的一些问题和特点总结归纳并形成的一些类的框架。”呵呵，我对MFC不太了解，但我觉得楼上说的也有道理，MFC应该是一种开发框架，但我觉得也不可否认MFC是和MFC这个结构有类似的地方，或者说神似吧。很简单的认为：Document影响View。下面是Vijay Ramachandran在《建造灵活与可维护的J2EE应用程序的设计模式》中对MVC的阐述：MVC结构可以映射到多层的企业级J2EE应用程序：1、所有的企业级数据与用于处理数据的事物逻辑都能用这个模型来表示；2、视图可以通过这个模型存取数据，然后决定如何将数据表达给客户。当模型改变时，视图必须确认给用户所表达的内容也跟着改变；3、控制器可以与视图交互，并且将客户的行为转换为模型可以理解与执行的行为。控制器也根据最新的客户行为与相关的模型行为来决定下一个要被显示的视图是什么。将上述的逻辑应用到实际项目中：1、应用程序的事务逻辑由组成MVC结构中的模型的EJB来代表。模型对来自控制器的要求作出反映，并存取/修改相应的数据；2、应用程序界面的不同屏组成MVC结构中的视图。当模型改变时，视图自动更新；3、应用程序的控制器是一些对象的集合，这些对象接收用户的行为，并且将其转换为模型可理解的请求，一旦模型完成了对请求的处理，就决定下一个要显示在屏幕上的内容是什么。Java宠物商店演示程序是一个很好的基于MVC结构的完整的J2EE应用程序的例子，可以参考参考。 楼上的可能没看清楚，我说的是MFC下的Document-View,而不是MFC MultiLayer是宏观的，适用于web，app,但MVC是微观的，MVC小到一个JTable有自己的模型，渲染/编辑器，大到一个绘图App，有View(Obserable),Controller(Observer)和Model,哪里有MultiLayer的概念广呀？了解Smalltalk，MFC的人都知道MVC的具体含义,我就不多说了。有人把web的设计模式也归于MVC此列了，这种说法，或许是广义的MVC,但是我想，熟悉MFC，Smalltalk的人不会这么认同。大多数人还是认为，MVC是MultiLayer的表示层的设计方法，而不是贯穿整个MultiLayer结构的设计方法。（你在数据层怎么MVC?呵呵)简单来讲：MultiLayer是 Presentation Tier，Presentation Tier，Data Services Tier.MVC是Model,View,Controller 嗯，可能你说的有道理。我熟悉mfc，对mvc的具体实现的一些方法和细节不熟悉。当然，也要排除具体的实现技术和方法与概念不能放在一起讨论。就好比Document-View模式和具体的实现方法不能一起来说。为此我才觉得Document-View的模式和概念角度上理解有一定的可比性。但是要拿MVC和MFC的D-V比起来，D-V更多的和MFC本身的设计思路关系密切。而MVC我认为是从对一些应用系统的开发模式，或者说系统架构的经验和认识抽象。MFC的D-V就更加局限于Windows平台，某一个方面了。所以我比较同意 xiaoyebing(深蓝大盗) 的理解。就好比J2EE和ASP/COM模式相比，可能在某个程度上可比，但前者实质上涵盖更多，不能放在同一层面上来说。另外，MFC已然很优秀，有很多问题不能用纯粹的面向对象技术来解决，MFC在这些方面做得很不错，这也许是让chenyuan_tongji(codeguru)觉得很烂的原因。MVC的确是一个优秀的设计模式，想必MFC的设计也肯定考虑过许多的模式（设计模式不会只有java才有）。愚见，请多指教。 to piggybank(吞硬币的小猪)你说得很有道理，这些都是有点模糊的概念，确实不同的人有不同的理解，但是都可以做出好的设计来。另外，其实MVC也有先天不足，MVC不是足够灵活，这个问题已经逐渐显现出来了，现在有很多人在研究比MVC更好的模式，但是就MVC对解决目前大多问题，是很优秀的。By the way, 我非常喜欢MFC, 尽管Bruce Eckle曾经说过，MFC是"他体验过的最糟糕的东西"，但是就像你说的，"有很多问题不能用纯粹的面向对象技术来解决", 这也是很有道理的，否则MFC决不会是现在这个样子。 XAException JNI报错 java进行IP地址格式化 高手进，与c有关！！！！！！ 一个线程间通信问题 一个初学者的问题（一定帮忙进来看看，拜托） 请 peacock_king(孔雀王)等参与讨论“读取配置文件的方法”的朋友进来一下。 java与mfc的通讯问题！ 日期如何计算 哪位大虾知道安装pushlet?请指教！ Java Application能不能在安装了JVM但没有装SDK的系统中运行? 哪儿有jb的书籍下载？20分钟内结贴
Java的MVC组织方式和MFC原理差不多，实现上有点差别。
是Model+Observable+Observer模式
关键是思想没变，所以很容易从MFC过来
比MFC容易10倍！决不夸张。
MFC我用了两年，也没成高手
我用了半年就很熟悉Java的类库了
（不过VC/MFC对我理解Java很有帮助）
struts的介绍你可去http://jakarta.apache.org/struts
mfc那套document-view，有点model+viewer的意思，不过一点也不优雅。
mfc真的很烂，很晦涩。
MFC是程序框架，是在Windows下开发应用程序的框架，是根据Windows下应用程序开发的一些问题和特点总结归纳并形成的一些类的框架。要勉强拿来和awt什么的相比，还能说得过去。
MVC要理解不妨从 Multi-tier 多层结构的开发模式角度来理解。它强调的是java提供的多种技术手段解决各自层面的问题，因此组合使用这些技术手段的方式就能影响到你的开发方式和思路。好比MVC把软件开发抽象成为 逻辑模块、视图、控制，对应就是用Beans来封装系统提供的底层功能模块，用JSP主要处理页面输出相关的东西--也就是表现层。另外还需要一些jsp程序或者servlet来实现控制--也就是你的软件系统提供的应用逻辑--比如用户登录该调用哪个bean，该用哪个jsp返回什么信息给用户。在系统设计人员的眼里来看，他把自己要开发的系统设计成为MVC这样的一个结构，并用java相应的技术去体现这样的层次结构。如果你要用微软的技术体系，同样的多层结构按我所喜欢的方式来做就是：经过仔细封装的数据库存储过程和基于ATL开发COM/COM+组件、进行应用逻辑控制的组件（允许用VB）或ASP Class/ASP、仅仅处理表现层的ASP。
在具体的模块中可以采用一定的设计模式，比如用存储过程来封装提供给COM组件的数据库存取层的逻辑，用class 来封装COM提供给asp的一些方法，就好比proxy那样提供给表现层的asp程序。显然，设计模式和MVC不是一个层面上的东西。这里关心的主要是如何把表现层的东西和应用逻辑以及系统底层模块分开，struct这一类的问题重点都是考虑如何在开发人员和他们的工作之间也能分出层次，并如何有效协作。显然这和MFC的Document-View技术不是一个层次的问题。
牛头不知道哪里去了？
“MFC是程序框架，是在Windows下开发应用程序的框架，是根据Windows下应用程序开发的一些问题和特点总结归纳并形成的一些类的框架。”呵呵，我对MFC不太了解，但我觉得楼上说的也有道理，MFC应该是一种开发框架，但我觉得也不可否认MFC是和MFC这个结构有类似的地方，或者说神似吧。很简单的认为：Document影响View。下面是Vijay Ramachandran在《建造灵活与可维护的J2EE应用程序的设计模式》中对MVC的阐述：MVC结构可以映射到多层的企业级J2EE应用程序：
1、所有的企业级数据与用于处理数据的事物逻辑都能用这个模型来表示；
2、视图可以通过这个模型存取数据，然后决定如何将数据表达给客户。当模型改变时，视图必须确认给用户所表达的内容也跟着改变；
3、控制器可以与视图交互，并且将客户的行为转换为模型可以理解与执行的行为。控制器也根据最新的客户行为与相关的模型行为来决定下一个要被显示的视图是什么。将上述的逻辑应用到实际项目中：
1、应用程序的事务逻辑由组成MVC结构中的模型的EJB来代表。模型对来自控制器的要求作出反映，并存取/修改相应的数据；
2、应用程序界面的不同屏组成MVC结构中的视图。当模型改变时，视图自动更新；
3、应用程序的控制器是一些对象的集合，这些对象接收用户的行为，并且将其转换为模型可理解的请求，一旦模型完成了对请求的处理，就决定下一个要显示在屏幕上的内容是什么。Java宠物商店演示程序是一个很好的基于MVC结构的完整的J2EE应用程序的例子，可以参考参考。
但MVC是微观的，MVC小到一个JTable有自己的模型，
渲染/编辑器，大到一个绘图App，有View(Obserable),
Controller(Observer)和Model,哪里有MultiLayer的概念广呀？
了解Smalltalk，MFC的人都知道MVC的具体含义,
我就不多说了。有人把web的设计模式也归于MVC此列了，
这种说法，或许是广义的MVC,但是我想，
熟悉MFC，Smalltalk的人不会这么认同。
大多数人还是认为，MVC是MultiLayer的表示层的设计方法，
而不是贯穿整个MultiLayer结构的设计方法。
（你在数据层怎么MVC?呵呵)
简单来讲：
MultiLayer是 Presentation Tier，Presentation Tier，
Data Services Tier.MVC是Model,View,Controller
当然，也要排除具体的实现技术和方法与概念不能放在一起讨论。就好比Document-View模式和具体的实现方法不能一起来说。为此我才觉得Document-View的模式和概念角度上理解有一定的可比性。但是要拿MVC和MFC的D-V比起来，D-V更多的和MFC本身的设计思路关系密切。而MVC我认为是从对一些应用系统的开发模式，或者说系统架构的经验和认识抽象。MFC的D-V就更加局限于Windows平台，某一个方面了。所以我比较同意 xiaoyebing(深蓝大盗) 的理解。
就好比J2EE和ASP/COM模式相比，可能在某个程度上可比，但前者实质上涵盖更多，不能放在同一层面上来说。另外，MFC已然很优秀，有很多问题不能用纯粹的面向对象技术来解决，MFC在这些方面做得很不错，这也许是让chenyuan_tongji(codeguru)觉得很烂的原因。MVC的确是一个优秀的设计模式，想必MFC的设计也肯定考虑过许多的模式（设计模式不会只有java才有）。愚见，请多指教。
你说得很有道理，这些都是有点模糊的概念，确实不同的人有不同的理解，
但是都可以做出好的设计来。另外，其实MVC也有先天不足，MVC不是足够灵活，这个问题已经逐渐
显现出来了，现在有很多人在研究比MVC更好的模式，但是就MVC对
解决目前大多问题，是很优秀的。By the way, 我非常喜欢MFC, 尽管Bruce Eckle曾经说过，MFC是"他体验过的最糟糕的东西"，但是就像你说的，"有很多问题不能用纯粹的面向对象技术
来解决", 这也是很有道理的，否则MFC决不会是现在这个样子。