web form最主要的优点是隐藏了大部分客户端和服务端的交互细节，使得开发员可以集中精力处理其他问题。但是我感觉压制了javascript的使用（web form下当然可以使用javascript，但是有诸多不便），容易把很多本来应该在客户端做的事情都搬到服务端来做，相比之下，asp.net mvc实现了客户端的数据绑定，并大大解放了javascript。虽然asp.net mvc缺少客户端控件，我开始觉得是个很大的缺点，但现在看，似乎微软有意只做framework，而把这一块交给jquery及其多如牛毛的plug-in来处理。业务逻辑还是主要在服务端（当然似乎很难避免javascript里也有一些业务逻辑），实现界面和业务的分离。 asp.net mvc还解决了web form由ViewState引起的影响性能的问题，还实现了RESTful风格，都很好。如果都用javascript做，那很容易就把界面的代码和业务逻辑混在一起，且不说javascript的安全性问题。
Web Service + Ajax 从理论上讲是好的，但是现在JavaScript frameworks/tools 都跟不上，实际开发起来会有很多问题。
个人很认同这句话，虽然在先前的项目中这一点做得不是很好（原因可能是多方面的），但是现在已经逐步在向这个原则靠近MVC与ASP.Net MVC是两个不同的东东，MVC的如果其他的设计模式一样，应用的面非常广，绝不仅仅局限于软件行业。 ASP.Net MVC有点不伦不类，从某些方面看，的确是这样 楼上的讨论很精彩，受教了..
http://hi.baidu.com/xykking/blog/item/bb0ec819ecf48e0d34fa4171.html写几个页面实践下 你就能感受部分区别了
重用性 适用性
维护 部署面试之前还是准备准备就好了
http://wenku.baidu.com/view/569b0ba1b0717fd5360cdc60.html
如果是asp.netMVC,先把@User.Name诸如此类的分离了再说,
分层的优势在于组件的可替换性和可重用性,
试想一下,如果实现了frmCustomer,还要再实现frmSupplier这些类似的业务,
每个页面都去写个View,那我看不出来是MVC的
mvc 就是 model，view，controller。
我们其实也可以把webfrom 这样来比喻：model实体类，view 我们的aspx，controller 像我们的cs文件。
只是mvc的model 比较广，实体类与显示实体类（这样说不准确）。
也就是说如果楼主 不是要自己去构架项目的话，你从webform转到 mvc 是一个超短的时期。
一样简单易用。
搂住想用jquery ajax，mvc下面也是很容易实现的。
html+ajax+ashx 这样确实不错其实已经有点MVC的思想了~ 不过MVC还是要学的~
1 .数据,要传来传去,从control传到view.如果你页面逻辑稍多一点.那么有些数据，使用强类型的还传不过去,要用viewdata["abclist"] as list<abc> 这种弱类型的传来传去，还在判定空呀，乱七八糟的2 .页面控件用不了,比如以前经常用的data绑定control的，那你写foreach了,如果有回传还得写回传后状态维护.感觉回到了asp时代...
当然了,如果页面逻辑复杂一点...asp时代那种面条式的编码方式我认为，是不可避免的个人认为，了解一下可以，没什么大的好处。
View也可以是面向对象的，webform已经把view面向对象化了，干嘛要走回去.
那您老的意思是view的还可以替换和重用了......您倒是把asp.net的mvc中的view复用给 Struts2 的view中去呢..
要不把html重用给其它的应用程序。比如画图。这不是讲笑嘛.最多业务层重用或是复用一下，还要看平台，要说重用和复用com+算不错了,说的好象webform的业务层不能复用和重用.
所以大家回答的都不准确。
ASP.NET不好在哪里？我也说不好，曾经看过一个帖是这样说的，ASP.NET基于FORM提交机制。靠VIEWSTATE来存储页面上的信息。生成了大量的VIEWSTATE，使页面加载速度变慢了（可以优化）。
而ASP.NET MVC不再是基于FORM机制。页面上没有自动生成的代码了。看起来更清爽。
ASP.NET MVC 采用了最原始的HTML的提交机制。
ASP.NET MVC 开发效率降低了。自己说迷糊了
1.有不同看法就直截了当说;反过来,你不懂得真正的分层设计,我不会取笑你;
2.在同一平台内,例如:一个OrdinaryView可以被所有基础信息管理类型的业务使用;
3.跨平台的,例如:一个OrdinaryView可以使用在winform,webform,SL,JAVA平台等任何平台,
只不过,每个平台都有一个平台专用的视图渲染器;
4.view的跨平台这也是小儿科的东西了,得益于分层设计,代码可以减少90%;
你如果不认同我的说法,请指正,
并且我说的都是我已经做到的,
我知道,有很多开发组织都能做到,并且,他们做得更好
Comparing Web Forms And ASP.NET MVChttp://msdn.microsoft.com/en-us/magazine/dd942833.aspx
客观的观点 优点与劣势,适用的场景等，分层的优势在于组件的可替换性和可重用性,那么反过来说webform不存在这样的优点吗？如果说你没用过webform.你怎么知道没有这样的优点
你能带给楼主一个有价值的评论吗？而很多情况下，你在讲，你不懂这，你不懂那.我还不懂怎么生孩子，请问，你会吗。
如果你的你心态再不改正，我不想就这个事情与你讨论了.你现在已经是一个抬杠的心态。
然后我回复你,我是如何做的,
接着你就搬出好多大道理来了,这只能证明你品德比我高尚,不能证明你质疑的正确性
你讲View的跨平台、减少90%的代码，对不对？那就是显示层如果，请问你这是平均，还是特定环境地下?我们就事论事一下，不过我有点忙，可能要明天或是后天回复，但是，我一定要把这个问题搞清楚。看到底是不是如果可以，我再拿出我这方面的一个报表.我们具体的测试一下，看能不能减少这么多代码，在winform与asp.net mvc之间，有没有问题，不要说简单的增删改查，那样的需求我们不做
100行左右的View端，来实现，如何?
利用任何平台都可以做MVC分层方式的开发,
这不是我发明的,到网上搜搜吧,现成的代码拿来看看
如果一个项目有500个界面,还有一个项目5000个界面,你的View是不是都一样,只有二三十个而已?
这就是极限编程理论的2个极限之一:代码总量是有极限的,不会随着项目规模的增长而增长,
VC的CDocment.CView我早用过了,一个文档对应多个视图。我都用过
我拿VC的mfc说事，指的是他有点象mvc这东西
view是数据无关的!数据使用户的东西,甚至用户自己都无法一次表达清楚,他们是不稳定的,不要硬编写在你的代码里
我再论坛里不止一次的贴出过我的代码,你可以去搜一搜,
我们的开发也是经历了从照抄petshop到开发原始的代码生成技术,再到开发自己的开发工具,
从原始的数据驱动开发,到现在的文档驱动开发,
这些都是实实在在的一步一个脚印走过来的,
做不到,我绝不会开这里空谈!
而且我说过,有些开发组织做的比我们还好得多
我也同意这个看法,
asp.net代理人机制的优势就在于隐藏了复杂的信息往返,WebForm在服务器端建立了一整套客户端模型,然后asp.net替你来渲染页面,使开发者能像开发传统客户端一样开发软件,
如果不能使用现成的服务器控件,那还不如直接html+js+WCF/WebService,
尤其是微软也通过MicroSoftAjax(注意.不是Asp.NetAjax)平台为客户端脚本提供了很好的接口,
所以要么asp.netWebForm做MVC,要么html+WCF做MVC
asp.net mvc还解决了web form由ViewState引起的影响性能的问题，还实现了RESTful风格，都很好。如果都用javascript做，那很容易就把界面的代码和业务逻辑混在一起，且不说javascript的安全性问题。
Web Service + Ajax 从理论上讲是好的，但是现在JavaScript frameworks/tools 都跟不上，实际开发起来会有很多问题。
先定义一个view model的class,然后把需要的class还有属性放到这个view model里面在view里面就可以调用了
@model IEnumerable<ProjectName.Models.ViewModelClass>
<ul>
@foreach (var item in Model)
{
}
</ul>
我感觉很大部分是因为servlet以及jsp的一些弱势制约
ms在推出net平台时针对这种情况做了诸多的改进，也就是为何ms一直坚守webform，在mvc已经满大街都是的情况下不紧不慢的推出个aspnet mvc，仅仅是多给了一种选择而已
至于开发到底用什么样的技术一方面是需求说了算，一方面是个人习惯，对于页面逻辑复杂用mvc显然不合适
至于重用完全是扯蛋，aspnet mvc可能直接拿到strus2吗
嗯.你有的很有道理.就面向对象来说,个人认为webform已经有一个高度了.那个谁，重用 90%的代码我可等着..事情算是结束了，但是你仍然没有拿出你的代码出来.
你要是把java的虚拟机指令整的能转8086指令，我也佩服你,也算你为重用做了一点贡献.
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/whizen/archive/2011/04/07/6307358.aspx
但是你的开发效率肯定不高了啊，你使用了太多的技术在里面。
一般胖客户端+低数据传输的才使用这一样的模式。
不知道楼主是否明白。
为什么不用webservice+soap+html+ajax来实现mvc的功能。理解胖客户端很重要。
但是你的开发效率肯定不高了啊，你使用了太多的技术在里面。
一般胖客户端+低数据传输的才使用这一样的模式。
不知道楼主是否明白。
为什么不用webservice+soap+html+ajax来实现mvc的功能。理解胖客户端很重要。
顶这个。换汤不换药。看你怎么理解了。MVC更灵活了。你看DZNT。这些用webform方式开发的不也一样是很好的产品嘛、。
只不过采用了模板技术。不是asp是页面.aspx.cs是代码这种方式。
个人很认同这句话，虽然在先前的项目中这一点做得不是很好（原因可能是多方面的），但是现在已经逐步在向这个原则靠近MVC与ASP.Net MVC是两个不同的东东，MVC的如果其他的设计模式一样，应用的面非常广，绝不仅仅局限于软件行业。
ASP.Net MVC有点不伦不类，从某些方面看，的确是这样
楼上的讨论很精彩，受教了..
比如View,可以这样创建输入视图:
public virtual void CreateView_Search() {
this.div_1_1.Controls.Add(ViewDrv.ParamViewDrv.CreateView(this.OrdinaryModel.MethodSearch.Params));
}//end CreateView_Search它可以创建任何方法的输入视图,完全数据无关
再举个例子,从视图获取输入然后提交更新:
protected string Delete() {
ViewDrv.ParamViewDrv.UpdateParams(this.gvwOrdinary.SelectedDataKey, this.OrdinaryModel.MethodDelete.Params);
DAHelper.ExecuteMethod(MyApp.ConnStr, this.OrdinaryModel.MethodDelete);
}//end Delete
就如同显示器和显卡的关系,再贴一个WebForm的页面实例:
<body>
<form id="form1" runat="server">
<ajaxToolkit:ToolkitScriptManager ID="Tsm1" runat="server"></ajaxToolkit:ToolkitScriptManager>
<asp:UpdatePanel ID="UpdatePanel1" runat="server">
<ContentTemplate>
<div id="divBody" runat="server">
</div>
</ContentTemplate>
</asp:UpdatePanel>
</form>
</body>
如果不是为了给手写代码留有余地,这个页面都不需要,直接自己处理url映射了,
ASP.NET MVC 实际上是从Model2进化过来的。Model2是因为Web development 而产生的一个MVC变种。所以ASP.NET MVC 并不是原始意义上的MVC。
我想请问你，你这个能在哪里重用?
我要你贴重用的代码..注意重用.肯定是二个不同的方面你别拿BLL的来重用了.连接字符串都写到view里面去了，信你的邪，怕自己封装功底不够，还在页面上留个小通道?
2.你说说看,我的代码哪里数据相关了?你看到有字段了?
3.至于你说的BLL,再贴给你看看:
public partial class OrdinaryModel : AppCenter4.IModel.IOrdinaryModel {
#region constructors
public OrdinaryModel(string pAppKey, string pFormName) {
#region 参数预处理
pAppKey = MyHelper.ToString(pAppKey);
if(pAppKey == "") throw new MyException("参数pAppKey不能为空");
pFormName = MyHelper.ToString(pFormName);
if(pFormName == "") throw new MyException("参数pFormName不能为空");
#endregion 参数预处理
this.FormName = pFormName;
this.GetFormMethod(pAppKey, pFormName);
}
#endregion constructors #region interface members
public StyleSoft.Common4.Models.Method MethodSearch { get; set; }
public StyleSoft.Common4.Models.Method MethodInsert { get; set; }
public StyleSoft.Common4.Models.Method MethodUpdate { get; set; }
public StyleSoft.Common4.Models.Method MethodDelete { get; set; }
public StyleSoft.Common4.Models.Method MethodSearchById { get; set; } #endregion interface members
你这不是瞎折腾吗。MVC只是个Shell, 跟Web Forms 用的是同一个runtime。好东西该学还得学。当然等真要用到的时候学效果会更好。
比如View在Web上的表现和View在各种显示平台的上,如Winform,如Flash,如Pdf 如JSP,
请问你表现了吗,技术是什么东西.弄个Com+的即时解释性的程序，你谈技术.
你的跨平台是指跨.net平台吗,跨.net下的 vb.net c#.net vc++.net ，你这平台跨的真多呀，只可惜，那是ms 的功劳..您的功能呢
您倒是跨一下软件平台或是虚拟机平台，或是各种cpu指令平台呢,跟你讨论真累.你要是看不懂我上面的话，您也别贴了，你不累我还看得累
要不你没理解我的意思，要不，你就在这抬杠，有意思吗？
他说的View有点类似“工厂模式”，更像是一个等待BLL来渲染的View模板，所以的确是可以重用的（可能我理解得也不是很准确）
但是zyug大侠说的View是指“工厂”加工后渲染出来的最终用户界面
我说实现原理,你说要看代码,我贴了代码了,你又说看的累我只针对你的技术问题回复,view和model的代码都给你看了,正如我之前所说,
设计时刻,代码中就没有数据,
Model对业务建模,View对业务的外观建模,他们都是数据无关,领域相关的,
UI只是显示器,每一种UI配备一个(注意:是一个)驱动器,负责将View渲染到UI另一方面,View是统一模型,业务就是说View的原型在文档中,代码只是实现了文档接口,
而文档对View的描述是不管它到底会运行的那种平台的,Model也是如此,
由文档驱动的开发,注定是可以快速重建和跨平台的运行时刻:Model被ModelDrv动态装入数据,组装到View,View被ViewDrv动态渲染到UI
谁找你要这种代码.什么drive什么驱动,没看你之前的代码，还以为你在写驱动.
搞得自己象个驱动专家在写驱动，本来很简单一件事，
硬是被你搞得这么复杂,还要叫嚣.你不懂，你不懂.忽悠人
好好学习一下计算机原理吧.你这种就是a调b.b调c,c调d.d调e...一直调到z....还要调用aa...到zzzzz
一个纸壳包一个纸壳...其实最终实现代码还是那么一点，反而中间多了N多参数检测...一个词形容你.过度包装.
但是真正到了每个不同的显示环境，又要写一大堆代码来配合这个显示环境，实际上最终的情况仍然是数据->显示
如果说你能改变这个.你可以无数的弯呀绕.,你这也叫View,再好好学习一下吧.
你谈的MVC,已经走样了，还要在这教育人
我谈论的技术话题,陈述的是事实,
你的那些众所周知的大道理证明不了在本贴话题上你的论点,
甚至到现在也没有看你有什么具体的实现手段,我倒不需要看你的代码,你只要把你的驱动链说清楚就可以了,顺便说一句:
MVC的驱动模式就是:无论你要多少组件,他们之间的驱动关系都是2级的,
MVC的核心思想就是:引入虚拟的组件来改善所有组件之间的驱动关系,
你只能写出链条式的驱动关系,不要想当然的套在别人身上
2."教育人"的是你吧?你不是一直叫我做人的道理的嘛,我照单全收了,没有反驳你一字半句;
3.如果你没有耐心看我的回复,你至少先把你自己所有的回复仔细看一看好再说话吧