MVC怎么样去理解，唉每一次知道MVC影响着程序编程的质量。 分别是：界面显示，界面显示的数据，界面对数据的影响控制，各种功能的线程。 其实，官话就是那个什么MVC形式。 我是从这里开始真正听说MVC 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 MVC有很多blog和以前的讨论的，你应该好好看看那些了，不用再一次发问的。MVC是非常灵活的，可以说是一种理念而已，不同的程序，有不同的体现。V就是UI了，UI可能是JSP，Servlet，HTML，WinForm，Silverlight等等。M就是数据模型~这个可能是数据持久层，可能是JDBC接口，可能只是一个数组，链表C就是Controller，Controller也有很多种，可能是Servlet，甚至可能没有代码(不需要用户写代码，框架完成了) 简单的说mvc 就是 model（模型） view（视图） controller （控制器）模型是用来写底层的数据。。例如javabean一类。视图就是用来显示数据。。例如用jsp显示。。而控制器就是他们两个之间的桥梁当然这只是最简单的理解如果你想深入学习去google搜一下就OK了。。有很多资料。。 MVC只是个概念.是一种思想.考虑这样一件事情,做一个程序提供一个界面,用户输入两个数和一个操作符然后提交,界面就会将答案算出来.如果是按照MVC的思想怎么做这个事?首先责任明确:1.V也就是界面,只负责显示和采集用户输入.也就是说,V不需要知道我自己是干什么的,我只需要把你给我的显示出来,然后把用户输入的记住然后在某个时刻给别人.因此对于V来讲他不面向业务,他就面向规范,你给为个文本,我就显示文本,等到用户输入文本,我就把输入记下来,等提交的时候,我再告诉其他人,用户在某个文本位置输入了什么,任务就完成了.考虑一下纯html,他就是这样的.但是为什么后来又要有js呢?这是因为一个应用程序除了纯业务需求,还有其他方面的需求比如交互需求等.比如我们可能要求,在输入界面,会有个文字提示不断变颜色之类的.当然,我们可以在显示的时候就告诉V说你如何如何,但是这样会导致后台与V的接口很不稳定,可能会不断增加.问题复杂了.所以我们创造出客户端脚本语言.后台给V信息的时候,除了要V显示,还给V个脚本,然后告诉V什么时候开始执行就行了.这样后台与V的接口稳定了,还是只用关注核心需求即可,至于V要显示什么特效,那就是改写那个脚本的问题,无论那里怎么改,对其他部分没有影响.同时由于脚本的引入,使的界面本身可以响应一些用户输入,比如用户输入0/0,我可以在V上就提示,不需要还要提交到后台再返回了.严格来说,这破坏了MVC的原则,但是这是基于最佳实践的考虑,而且必须要清楚,就算V端进行了一些检查,在后台这些检查还是要进行的.总结一下,V的输入是要显示什么,然后做些什么.输出则是用户在什么位置输入了什么.而现在B/S的情况是这样的,V越来越重要,大家都喜欢漂亮门面嘛,所以各种效果布局很复杂.这时候更要感谢MVC,因为不管你怎么在V上面折腾,做后台的人只要确定V把我需要那几个文本框显示了并可以提交了就行.其他的你随便折腾.2.再考虑C也就是控制器.从V过来的数据怎么办?比如说我们的例子会过来+,a,b和-a,b,你当然可以统一处理,但是更多情况下,你肯定还是希望可以分一下类,比如把+和-操作分开处理.那么就需要C了.C拿到V传过来操作和操作数,然后开始根据约定(大多情况是配置的),将+操作转给处理+操作的代码,将-转给处理-操作的代码.遇到不认识的,就交给错误检查页面.以后你支持*了,那就写个处理*的代码,然后在C里配置上,不会对+,-造成任何威胁.想想看,如果最初你是混在一些处理的,当你在那一大坨代码中再加上*处理的代码时,你还敢信心满满的说+,-都不需要测试,没问题的么?3.最后是号称数据模型的M.其实这个层才是程序员的主战场.V是给用户看的,理论上由美工完成(尽管很多公司还是程序员干).C是帮助分解问题域的,这些在设计阶段就确定了,而且一般都很形式化,没什么写头.而且M本身就是可分很多层的.比如Service层,DAO层.其实一般公司的framework都是对这层的规定.这部分内容太多了,不说了.其实现在还有一些实现和上面的不太一样,上面说的是横着一层层的分开.现在有些架构的思想是竖着一片一片的,把业务切开.降低业务复杂度.然后在片内按照一些约定直接完成VCM的组合.效率很高. MVC怎么会是设计模式。Gof 23种设计模式中，没有这一项。 上google打mvc设计模式马上就会搜索出好多，你理解了mvc中各个字母代表的意思，就知道它为什么是设计模式了，如何你还不了解，可以去看看软件体系结构 急，高手指教，用poi来解析.doc,docx,rtf,txt 这两个程序的运行结果为何不同? 一个关于java内部类的问题 谈谈用JAVA业验证邮箱是否有效的验证 关于字符串扣留 提个问题 JAVA都是在堆中创建吗？ 小问题：请各位帮忙解决哈！！！ 求一个正则 为什么老是报 double free or corruption (fasttop): 0x0000000000abf110错误呢? java代码日历 try....catch...finally
MVC是非常灵活的，可以说是一种理念而已，不同的程序，有不同的体现。V就是UI了，UI可能是JSP，Servlet，HTML，WinForm，Silverlight等等。
M就是数据模型~这个可能是数据持久层，可能是JDBC接口，可能只是一个数组，链表C就是Controller，Controller也有很多种，可能是Servlet，甚至可能没有代码(不需要用户写代码，框架完成了)
模型是用来写底层的数据。。例如javabean一类。视图就是用来显示数据。。例如用jsp显示。。而控制器就是他们两个之间的桥梁当然这只是最简单的理解如果你想深入学习去google搜一下就OK了。。有很多资料。。
如果是按照MVC的思想怎么做这个事?
首先责任明确:
1.V也就是界面,只负责显示和采集用户输入.也就是说,V不需要知道我自己是干什么的,我只需要把你给我的显示出来,然后把用户输入的记住然后在某个时刻给别人.
因此对于V来讲他不面向业务,他就面向规范,你给为个文本,我就显示文本,等到用户输入文本,我就把输入记下来,等提交的时候,我再告诉其他人,用户在某个文本位置输入了什么,任务就完成了.考虑一下纯html,他就是这样的.但是为什么后来又要有js呢?这是因为一个应用程序除了纯业务需求,还有其他方面的需求比如交互需求等.比如我们可能要求,在输入界面,会有个文字提示不断变颜色之类的.
当然,我们可以在显示的时候就告诉V说你如何如何,但是这样会导致后台与V的接口很不稳定,可能会不断增加.问题复杂了.所以我们创造出客户端脚本语言.后台给V信息的时候,除了要V显示,还给V个脚本,
然后告诉V什么时候开始执行就行了.这样后台与V的接口稳定了,还是只用关注核心需求即可,至于V要显示什么特效,那就是改写那个脚本的问题,无论那里怎么改,对其他部分没有影响.
同时由于脚本的引入,使的界面本身可以响应一些用户输入,比如用户输入0/0,我可以在V上就提示,不需要还要提交到后台再返回了.严格来说,这破坏了MVC的原则,但是这是基于最佳实践的考虑,而且必须要清楚,
就算V端进行了一些检查,在后台这些检查还是要进行的.总结一下,V的输入是要显示什么,然后做些什么.输出则是用户在什么位置输入了什么.
而现在B/S的情况是这样的,V越来越重要,大家都喜欢漂亮门面嘛,所以各种效果布局很复杂.这时候更要感谢MVC,因为不管你怎么在V上面折腾,做后台的人只要确定V把我需要那几个文本框显示了并可以提交了就行.
其他的你随便折腾.
2.再考虑C也就是控制器.
从V过来的数据怎么办?比如说我们的例子会过来+,a,b和-a,b,你当然可以统一处理,但是更多情况下,你肯定还是希望可以分一下类,比如把+和-操作分开处理.那么就需要C了.C拿到V传过来操作和操作数,
然后开始根据约定(大多情况是配置的),将+操作转给处理+操作的代码,将-转给处理-操作的代码.遇到不认识的,就交给错误检查页面.以后你支持*了,那就写个处理*的代码,然后在C里配置上,不会对+,-造成
任何威胁.想想看,如果最初你是混在一些处理的,当你在那一大坨代码中再加上*处理的代码时,你还敢信心满满的说+,-都不需要测试,没问题的么?
3.最后是号称数据模型的M.
其实这个层才是程序员的主战场.V是给用户看的,理论上由美工完成(尽管很多公司还是程序员干).C是帮助分解问题域的,这些在设计阶段就确定了,而且一般都很形式化,没什么写头.
而且M本身就是可分很多层的.比如Service层,DAO层.其实一般公司的framework都是对这层的规定.这部分内容太多了,不说了.其实现在还有一些实现和上面的不太一样,上面说的是横着一层层的分开.现在有些架构的思想是竖着一片一片的,把业务切开.降低业务复杂度.然后在片内按照一些约定直接完成VCM的组合.效率很高.
Gof 23种设计模式中，没有这一项。