不要为了mvc而mvc 大家进来讨论下都

你首先要了解一个框架的意义，他的存在价值不是外行人所能了解的MVC字面上的意思就是模型、视图(显示模板)、控制器(控制显示哪个模板)一个模型可以用多个显示模板进行显示(比如说文字列图，图片列表，大图列表等)，通过控制器来控制显示哪个模板，这个MVC的核心内容最常见的应用

不是说了么我也不是新手了
mvc mvp 甚至mvvm 我都了解也开发过
只是觉得mvc没有真的给我带来实惠呵呵

不是说了么我也不是新手了
mvc mvp 甚至mvvm 我都了解也开发过
只是觉得mvc没有真的给我带来实惠呵呵当你的技术达到一个位置时自然会明白，MVC不是指vs里的MVC，而只一种概念，他可以用任何方式来实现，可以与工厂模式共存，也可以是PHP和Java的,这就是所谓的不要为了框架而框架的意思

不是说了么我也不是新手了
mvc mvp 甚至mvvm 我都了解也开发过
只是觉得mvc没有真的给我带来实惠呵呵当你的技术达到一个位置时自然会明白，MVC不是指vs里的MVC，而只一种概念，他可以用任何方式来实现，可以与工厂模式共存，也可以是PHP和Java的,这就是所谓的不要为了框架而框架的意思
好吧原来是我low了其实我就是想问问它带来的好处
以及我们在构建项目时候如何选择webform 或者mvc的项目进行开发
当然原来我也写过java code mvc的概念我是在java里面了解到的
那好比如果现在你自己写项目会选择普通的webform 还是mvc项目来开发表现层呢？

如果没有特定要求(你们老大或客户的要求)，那当然是自由发挥，哪个写得快且效率当然就怎么写了，我们抛开vs里mvc的模型，不是还有动软代码生成器之类的工具吗，只要能以最快的方法实现才是你们老板所需要的

MVC是一个事实标准的web后端架构，它解决了将url请求、web前端页面和后端逻辑分开的问题。它是解决特定问题的特定框架而已。如果你认为它可以让你写程序更不动脑筋，或者平添了很多优势，那是你被某些无良的技术文章误导和忽悠了。

我说了，因为MVC是一种事实上标准的架构，所以一个用asp.net mvc开发的网站，可以很容易用struts或者ror改写，反之亦然。你用asp.net webforms的话，你用jsp改写下试试？

恩恩只是觉得大家都在大谈mvc
其实个人没有发现它能够带来的特别大的优势
也许是我的项目没有它发挥的优势
所以才感觉webform 处理得当一样好用其实我还想请教下是不是mvc对于自动化测试比较好
如果用传统的webform 如何搭建良好的unit test的项目框架呢？
unit test的覆盖是不是就到dal ->bll 这层了
不过说实在的 web ui展示层的测试大部分还是靠人工。。

ui测试本来就靠人工（或者说模拟人工）VS2010开始，微软增加了一个基于代码的UI测试（Coded UI Test）的组件，允许你手工操作界面，并且录制成脚本，以后用脚本模拟操作它实现UI自动测试。http://blogs.microsoft.co.il/eranruso/2010/03/27/visual-studio-2010-coded-ui-test-user-guide-create-a-simple-coded-ui-test/

webform把本来很简单的web开发变得复杂，说句不好听的，谁用谁吃亏。况且，MVC跟Webform没有什么关系。MVC是一个概念，不是具体框架或工具。

那原来你都用什么开发呢？
纯html ajax调用后台处理？
那样有点锻炼前端js功力的意思啊

首先大行其道的并不一定就是好的，更不一定就是你需要的。比如说我从2005年第一次接触webform，我就知道它不是我要的，我要的是html+js，虽然那时候的“ajax”实现手段与现在不同。
另外asp.net mvc是一个框架实现，并不能指代mvc这个概念，mvc的效应也不是仅仅止步于mvc的概念。就好像人类学会了使用金属，不是只有简单的字面上的意义。
看起来楼主有点抗拒js，这是很正常的，所谓术业有专攻，只做一件事效率应该是比较高的，而且是舒心的。
逻辑与UI分离，很可能起到同样的作用，分而治之很可能思路没那么混乱，干起活来更舒心了。当然这也只是可能，对于有些人有些情况来说也可能觉得更麻烦了。不同的人感觉不同吧。
如果你要说换数据库，这点应该反而是ORM的优势。比如数据库不一定支持存储过程，数据库不一定非得是关系数据库，数据库一定支持SQL语句，SQL语句也不一定能兼容。一般的ORM都能轻松的永久解决这些问题，当然也有一些ORM没有这功能。
如果要换开发语言，一般来说数据库这一块真不是什么大事，除非你的程序就是个企业管理器的扩展。如果做web开发的连js都抗拒的话，还能换个什么省心的语言。
楼主提到少量服务器控件+jquery，说明已经开始排斥webform了。如果有需要的话，可以考虑把这些都改成客户端控件，使用ajax与服务器交互，这时候就可以学习与了解一些前端UI框架(不是jquery这种类库哦)。
比如说传统的UI操作可能是这样的
$(XXX).html("<a href='"+href+"'>"+title+"</a>");
而基于web视图的UI操作可能是这样的，注意这里改变是的所有与XXX有关的界面内容。
XXX.Set({href:href,title:title});
如果体会不到某种开发手段的好处的话，说明至少现阶段不适合使用该种开发手段。

当你对非常相似的UI编程50遍的时候，你copy了一大堆UI代码，理由只是“他们有一些差别啊，所以只能垃圾copy！”这个，那么这时候就体现出UI层进行再进行分层的好处了。因为将UI中凡是“数据参数”的部分单独抽象出来，你就可以写“从M到V的自动化映射代码”，也就是说可以大量地使用模式匹配来自动化生成代码。可能是因为asp.net mvc比较垃圾，没有强调“非编程的程序设计模式”，所以让这种分层的好处化作乌有。只要是你不懂“少写代码才是编程的根本”，你以为什么都是copy代码然后修改它，你就不能理解大多数分层模式。

比如说，复杂的新浪新闻页面跟同样复杂的凤凰新闻页面有多大区别？差别很大吧？但是它们的Model层完全可以是一样的！而从Model到View以及处理各种交互响应事件，完全可以用模板自动化、标准化地生成和发布（不需要手工编码），这就是MVC要告诉你的。

正因为采用MVC设计模式,UI层就不需要人工测试了,
MVC的UI可不是靠人工编写代码的,而是由视图控制器渲染的,vs提供的脚本录制的测试方式实际上对拥有自动化测试能力的开发组织没有多大帮助

你把webform中的page也当作是一层控制器来使用,同样可以实现MVC的设计模式,
通过路由约定就可以实现不同的视图模型和业务模型的组合,生成所需的各个UI

Model并不一定只涉及业务数据，实际上UI控件所需要的、属于可以灵活调整的数据属性，都可以放到Model中。进一步地，各种数据处理行为也放到Model中。结果，你的UI中混合的大多数代码，都可以放到Model中。剩下的代码（剩下的View层）基本上不需要手工编程，而是需要美工人员进行数据绑定！

对于一个具体的工具有什么问题，我们可以具体讨论它的问题。例如我就肯定不使用asp.net mvc。但是不要扩大到没有边际的方面，不要否认原理和模式的重要性。

表太理想化了。
你用MVC，可能是因为老板需要或者客户需要，你可能无法体会到它的理论优点；
而你不用MVC，也可能是项目日程需要，开发人员技术门槛不够等等因素，你同样体会不到不用的缺点；所以，该干啥干啥，没必要纠结。程序员就是一般苦逼的人

mvc的model跟“三层”的model不是一个概念，要注意！三层中的model，用来跨三层而进行通讯。而mvc中的model，集中在UI层内部更底层的数据建模需求，因此mvc的model包括了一部分界面组件才需要的属性。我从来没有听说过什么用户需要mvc。基本上所谓“老板需要mvc”也是出现在很小的公司里，因为程序员基本上都是实习生，所以只能搞点简单概念进行僵化模仿，对他们不能要求什么设计知识。事实上老板如果花好5年时间还在只会强调“mvc”呢，我觉得这其实是一种讽刺（当非常耐心地给他们介绍mvc的时候，这个老板其实可能心里是瞧不起程序员的），这个开发组大概只能如此了。因此作为一个程序员，如果觉得“死猪不怕开水烫，俺就这个水平，你说啥就是啥，反正我无所谓学习”，那么小公司的老板就该偷偷哭去了（尽管他表面上还在夸这样的程序员）。

这其实是最简单的模式，懒得讨论。我们只是介绍一下概念而已。我见过一些公司花了较多的钱聘请的几个程序员整天纠结于这类东西吵来吵去，而整个公司开发层次很低很低，一切都是“分解一下界面，然后各自开发”的小作坊式的。这其实就是因为老板只会弄最简单的简单mvc模式分层，而不会直截了当地从更高开发效率的组件设计层次的设计入手。

首先大行其道的并不一定就是好的，更不一定就是你需要的。比如说我从2005年第一次接触webform，我就知道它不是我要的，我要的是html+js，虽然那时候的“ajax”实现手段与现在不同。
另外asp.net mvc是一个框架实现，并不能指代mvc这个概念，mvc的效应也不是仅仅止步于mvc的概念。就好像人类学会了使用金属，不是只有简单的字面上的意义。
看起来楼主有点抗拒js，这是很正常的，所谓术业有专攻，只做一件事效率应该是比较高的，而且是舒心的。
逻辑与UI分离，很可能起到同样的作用，分而治之很可能思路没那么混乱，干起活来更舒心了。当然这也只是可能，对于有些人有些情况来说也可能觉得更麻烦了。不同的人感觉不同吧。
如果你要说换数据库，这点应该反而是ORM的优势。比如数据库不一定支持存储过程，数据库不一定非得是关系数据库，数据库一定支持SQL语句，SQL语句也不一定能兼容。一般的ORM都能轻松的永久解决这些问题，当然也有一些ORM没有这功能。
如果要换开发语言，一般来说数据库这一块真不是什么大事，除非你的程序就是个企业管理器的扩展。如果做web开发的连js都抗拒的话，还能换个什么省心的语言。
楼主提到少量服务器控件+jquery，说明已经开始排斥webform了。如果有需要的话，可以考虑把这些都改成客户端控件，使用ajax与服务器交互，这时候就可以学习与了解一些前端UI框架(不是jquery这种类库哦)。
比如说传统的UI操作可能是这样的
$(XXX).html("<a href='"+href+"'>"+title+"</a>");
而基于web视图的UI操作可能是这样的，注意这里改变是的所有与XXX有关的界面内容。
XXX.Set({href:href,title:title});
如果体会不到某种开发手段的好处的话，说明至少现阶段不适合使用该种开发手段。感谢您热心的回答
其实不是特别纠结js 而且我也说了个人也比较喜欢纯净的html+js
问题在说的明白点
如果现在您要自己搞个web项目
您会采用什么样的架构呢？
要考虑今后可能会从微软系的架构切换到java系的架构
请问您有什么建议呢要考虑哪些问题呢？

以前刚开始用mvc的时候也觉得很烦,根本没有必要,现在用着觉得还挺带感的,不用的话总是觉得无从下手首先mvc的存在是为了让术业专攻,后台的做后台的M,前台的专注与前端的v,
然后让对这软件内容领域熟悉的人来做C层实现对接
这样可以提高效率和质量比如我做个计算器,实现加计算
后台做个函数
前端设置结果的显示位置,
由controller来获得前端的两个加数,然后调用后台函数,算出结果再给前端显示
像这样,前端可以找个精通html和js,css的人来做个好看的页面,炫酷的效果,他只需要懂html和js,css就行了
后台就找个算法高手做,他无需知道任何一点关于html和js,css的知识不过现在一个人做的时候用mvc也挺好的,实现了代码的分离,哪个部分出现问题,可以直接去那个地方找,便于维护虽然程序的所有代码都可以用1个页面实现,但这样不就显得繁琐?所以我们一般做程序都用多个页面写代码
个人觉得mvc只是把我们想要分开写的代码,通用地官方地分成了mvc 3个大类别.其实我做web的时候虽然习惯用mvc3
但是v层我一般也分3个类别html,css,js
这样布局直接html,样式调用css文件,再在js的分类文件夹中控制html中的元素行为
这样看起来比较清爽,也便于维护我一直想直接在html中用各种<div>标签+id 分割各个模块,
然后在css中根据id分别设置各个div元素的大小位置什么的属性
最后在js文件中设置各个div的行为
这样用起来会让我整个人都觉得清爽
但是太不现实了,像input,img,a什么标签用<div>+css+js实现起来超麻烦
大部分标签其实都整合封装了功能,我们使用时候直接一个标签了事,非常便捷,
因为是类似封装的,无法完全,清晰明了地控制到最底层,总感觉十分别扭,不够清爽
果然分离和便捷两件事就是矛与盾,无法绝对倾向哪个,现在的html用法大概就是中和了2个方面所得出来的一种用法吧,不上不下地orm还是比较便利的,省了你大量代码的编写,但是不够灵活,有很多冗余,考虑效率或者用不习惯还是自己写好了至于ado和存储过程
ado是为了便于对数据库操作的封装,比如你换了数据库编程语言没变,那么ado的代码大多不需要改变,方便你换数据库
如果数据库不便,而是换开发语言,那么存储过程比较方便,如果换语言的话,你不是.net开发的话还怎么用ado

服务器端仅仅定义UI视图class，并自动生成客户端调用数据接口(一般来说就是把class转换成JSON)。
客户端根据约定的数据接口规则自动使用ajax获取数据并根据UI模板生成UI界面。
这样子写一个普通的展示页面只需要做两件事，一是服务器端定义UI视图class并给数据赋值，二是UI模板数据绑定(如果你的UI模板规则简单的话完全可以交给美工做)，其他的工作都可以自动化处理。
不管服务器端换什么语言，都只需要提供同样的数据接口即可。而客户端仅仅与数据接口相关，无需任何改动。我认为设计模式是给不想事的初学使用的一个方法论。

UI视图并不是非要一个页面匹配一个，比如你可以建立一个全局UI视图，所有页面都只用它。
当有新的数据需求的时候，就给它添加一个新属性。
这样做有一个问题，就是很可能需要为新属性的命名而烦恼。

首先大行其道的并不一定就是好的，更不一定就是你需要的。比如说我从2005年第一次接触webform，我就知道它不是我要的，我要的是html+js，虽然那时候的“ajax”实现手段与现在不同。
另外asp.net mvc是一个框架实现，并不能指代mvc这个概念，mvc的效应也不是仅仅止步于mvc的概念。就好像人类学会了使用金属，不是只有简单的字面上的意义。
看起来楼主有点抗拒js，这是很正常的，所谓术业有专攻，只做一件事效率应该是比较高的，而且是舒心的。
逻辑与UI分离，很可能起到同样的作用，分而治之很可能思路没那么混乱，干起活来更舒心了。当然这也只是可能，对于有些人有些情况来说也可能觉得更麻烦了。不同的人感觉不同吧。
如果你要说换数据库，这点应该反而是ORM的优势。比如数据库不一定支持存储过程，数据库不一定非得是关系数据库，数据库一定支持SQL语句，SQL语句也不一定能兼容。一般的ORM都能轻松的永久解决这些问题，当然也有一些ORM没有这功能。
如果要换开发语言，一般来说数据库这一块真不是什么大事，除非你的程序就是个企业管理器的扩展。如果做web开发的连js都抗拒的话，还能换个什么省心的语言。
楼主提到少量服务器控件+jquery，说明已经开始排斥webform了。如果有需要的话，可以考虑把这些都改成客户端控件，使用ajax与服务器交互，这时候就可以学习与了解一些前端UI框架(不是jquery这种类库哦)。
比如说传统的UI操作可能是这样的
$(XXX).html("<a href='"+href+"'>"+title+"</a>");
而基于web视图的UI操作可能是这样的，注意这里改变是的所有与XXX有关的界面内容。
XXX.Set({href:href,title:title});
如果体会不到某种开发手段的好处的话，说明至少现阶段不适合使用该种开发手段。感谢您热心的回答
其实不是特别纠结js 而且我也说了个人也比较喜欢纯净的html+js
问题在说的明白点
如果现在您要自己搞个web项目
您会采用什么样的架构呢？
要考虑今后可能会从微软系的架构切换到java系的架构
请问您有什么建议呢要考虑哪些问题呢？
如果我是你，我只会先确定我用哪一种语言，比如Java，C#，PHP等等，除此以外的我不考虑。我不会从具体框架开始，我甚至不会假设我做的是web程序或web API或桌面程序。我会先从逻辑层下手，用TDD（测试驱动）的方式把逻辑层建立起来。当然了，逻辑层是需要依靠其他低层的，但是没关系，在Unit Test中mock就可以了。逻辑层跑通了以后，我再来考虑其他的。Always leave yourself in a open position. Always delay making decisions.

因为自己有前端的功底吧，我觉得mvc用起来非常方便，至少个人这样应为，而且很好的配合自己写jquery插件

mvc虽然用了才不久，了解也不够深入，但是那种多主题，多模板的快捷更换还是倍喜欢

web form 是目前为止最好、最高效的网页程序开发工具，而之所以webform不受欢迎，原因主要是有2点：1：webform太难！！ webform的工作运行原理一个程序员至少需要认真学习和实践使用2、3年时间才能基本上了解，要游刃有余的试用甚至需要更长事件。2：Webform没有做到极致，甚至说有点虎头蛇尾，框架前期设计理念上很好，但到后面，忽略了客户端功能开发，很多东西没有做到极致。

调试易

不要为了mvc而mvc 大家进来讨论下都

解决方案 »