InfoQ

InfoQ

新闻

我的书签

登录注册 以永久保存书签。

该内容已经被标记书签!

标记书签错误,请重试!

Chad Myers和Jeremy Miller对ASP.NET MVC开发人员的建议

作者 Jonathan Allen 译者 赵劼 发布于 2008年12月21日

领域
语言 & 开发
主题
ASP.NET MVC ,
Web框架 ,
ASP.NET ,
.NET ,
最佳实践 ,
架构 ,
编程 ,
MVC
Chad Myers和Jeremy Miller对于开发人员究竟该如何使用ASP.NET MVC提出了有力地建议。他们在上个月的KaizenConf会议上提出了这些准则化的建议。下面内容摘自Jeremy的总结
 
他们建议的重点是,大大强调了对控制器所承载功能的限制。在他们的设计中,控制器表层绝对以数据为中心,所有的输入均为单个ViewModel。由于没有暴露出HttpContext的任何方面,开发人员可以轻松地对控制器进行单元测试。
 
控制器除了不应该暴露出HTTP特性之外,它们还应该包含尽可能少的业务逻辑。
控制器应该非常薄。控制器Action方法唯一的任务是将传入的模型转化成合适的服务调用并创建输出用的模型。所有业务逻辑的职责应该由非表现层的类来承担。换句话说,控制器中并不包含业务逻辑。
没错,就是这样。在他们的观念里,MVC并不代表一个应用程序中的所有内容,开发人员应该使用额外的东西来处理真正的数据操作和存储。
 
还有很多东西值得思考,不过我们现在直接去看那些有关视图层中HTML和JavaScript的问题。
服务器端的标记绝对不应该和客户端JavaScript混在一起。我们建议遵循这个准则,因为这种很常见得错误做法往往造成难以阅读的代码,并且无法使用TDD的方式开发客户端JavaScript代码。我们不允许这种代码:callFunction('<%=Model.Variable%>')。如果服务器端数据需要传递到客户端的JavaScript中,我们会写成如下形式:“var something = <% =Model.Variable%>”。
视图应该非常简单。如果你在使用if/then语句或者循环,那么就说明你可能做错了。条件逻辑应该属于控制器或JavaScript类库等能够被单元测试的代码。把视图中的逻辑移出难以测试的代码,并放入易于测试的代码中可以有效地避免错误发生——没错,我认为JavaScript代码易于测试。Tag Soup也可以避免,我们倾向于使用自己的实现来替代循环,例如:<%= this.RenderPartialForEachOf(m => m.Solution.Resolutions).Using<EditResolution>()%>。在这段代码中,EditResolution为一个ASCX控件,m.Solution.Resolutions是一个IList<Resolution>类型的属性。这条语句会遍历这个列表,为每个Resolution对象生成一个部分视图。

查看英文原文:Chad Myers and Jeremy Miller: Opinions for ASP.NET MVC Developers

译者 赵劼 网名为老赵,洋名Jeffrey Zhao,写有技术博客“老赵点滴”。关注前沿技术,并致力于开源社区与微软平台的组合优化。

说实话我不同意他们的部分看法 发表人 Zhao Jeffrey 发表于
  1. 返回顶部

    说实话我不同意他们的部分看法

    发表人 Zhao Jeffrey

    例如关于表现层的循环,判断的看法。