在处理ASP.NET MVC与ASP.NET Web窗体的生产力时,请考虑这两个开发人员.
该通用.NET开发将是最有效的在原编写代码ASP.NET Web窗体.这是因为他们非常了解事件模型(因为它们在WinForms和WebForms之间进行镜像),并且能够使用此心智模型快速构建网站.
在通用Web应用程序开发将是最有效的ASP.NET MVC,因为该框架反映了他们是怎么想的Web应用程序-没有活动,没有应用程序的状态等,他们已经知道如何写出好的HTML和CSS使用它的风格,他们知道如何将ajax调用写回服务器.
我的主要观点是,不同的开发人员将根据他们以前的Web开发经验提供不同的生产力水平.我个人更喜欢ASP.NET MVC,我可以很快地构建一些东西并让它输出我想要的东西.
我是第二类开发人员,我在Ruby on Rails,Django,ASP.NET Web Forms和ASP.NET MVC中编写了Web应用程序(大多数都很小).这3个框架之间的Web开发知识几乎可以互换(除了必须知道托管语言 - ruby与python与c#之外).
我发现ASP.NET Web Forms最令人愤怒的事情是它试图为开发人员做太多事情(比如应用程序状态,Web事件),代码输出通常不能很好地与Web标准一起使用,Web Forms 2.0是直接绑定到XHTML 1.0 Transitional.与在ASP.NET MVC中编写它相比,任何超出数据库中快速和脏的DataGrid和Form到CRUD行的东西通常会带来更多的痛苦和痛苦.
没有.就个人而言,我发现MVC的工作方式更像是我的大脑所做的工作,非常清楚地分离了什么在哪里以及为什么.几个星期后,我用MVC打败了一个完整的原型商务网站,我敢肯定,至少会使用网络表格的两倍.
使用MVC,您永远不会花时间尝试解释为什么ItemDataBound和ItemCommand在您期望它们时不会触发.
如果你认为这会节省你的时间,那么MVC可能适合你.
此时,WebForms更加成熟.我希望,例如,验证(客户端和服务器端)在MVC中有更好的支持.但是,我完全相信,随着时间的推移,这将会有所改善.从我的角度来看,关于MVC的最好的事情是MVC使我的代码更易于测试.我遗留了大量未经测试的WebForms代码,因为它很难测试代码隐藏.现在我可以为所有控制器逻辑编写单元测试.
即使它最终证明MVC有点慢(而且我猜它不会),增强的可测试性将使它值得.最终我会收回那个时间,因为以后会有更少的回头修复错误,未经测试的代码.
| 归档时间: |
|
| 查看次数: |
4099 次 |
| 最近记录: |