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为一个ASCX控件，m.Solution.Resolutions是一个 IList类型的属性。这条语句会遍历这个列表，为每个Resolution对象生成一个部分视图。”
而对DNN来说, Asp.Net MVC将意味着什么呢? 有兴趣者不妨看看这一文章:ASP.NET MVC – Web Forms 2.0? , 其中有一段话如是说:
DotNetNuke is firmly planted in the Web Forms camp. While there may be new approaches, that we can consider, and lessons that we can learn, it is not likely that we will convert the DNN platform to be built using the new MVC Framework. At least not anytime soon.
最终的结论就是DNN将暂时坚守传统Asp.Net Web Form的阵地, 不会迁移到Asp.Net MVC框架上, 但是有所借鉴和吸收MVC的部分思想和模式. Enjoy DNN :)