Chad Myers 和 Jeremy Miller 对于开发人员究竟该如何使用 ASP.NET MVC 提出了有力地建议。他们在上个月的
KaizenConf 会议上提出了这些准则化的建议。下面内容摘自
他们建议的重点是，大大强调了对控制器所承载功能的限制。在他们的设计中，控制器表层绝对以数据为中心，所有的输入均为单个 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 为一个 ASCX 控件，m.Solution.Resolutions 是一个 IList 类型的属性。这条语句会遍历这个列表，为每个 Resolution 对象生成一个部分视图。
查看英文原文： Chad Myers and Jeremy Miller: Opinions for ASP.NET MVC Developers
评论