BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Jonathan Allen 关注 530 他的粉丝 ,译者 赵劼 关注 4 他的粉丝 发布于 2008年12月22日. 估计阅读时间: 3 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!
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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

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

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

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT