Asp.net MVC tips -- 也做为 要写漂亮的代码 (2)

  被称为一个漂亮的Asp.net MVC应用，从代码角度来看，我认为得满足这三点：

1. 使用依赖注入框架。

2. 不要直接依赖Cache， HttpContext等。

3. View中不要条件逻辑。

  当然不只是这三点，还有很多。我个人拿它们出来，是认为这些很重要但是经常被忽视。

 

  对于第1点，优点在于松耦合，可测试性很好。如果在Controller里面想要使用某些Service，要么new出来，要么用单例的形式，如UserService.Instance，这样想对Controller写单元测试都不容易，它和这些Service耦合太紧密，无法将这些Service替换成Stub实现。因此，松耦合是必须的。要实现这个功能，必须让依赖注入框架来创建Controller，才有可能注入依赖并组装对象。MVC里面有一个ControllerFactory的东西，可以使用来达到这个目的。

  a. 写一个类，继承自DefaultControllerFactory，例如 UnityControllerFactory : DefaultControllerFactory

  b. 覆盖方法GetControllerInstance，使用依赖注入框架来创建Conroller

  c. 修改Global.asax.cs, 在Application_Start内注册使用自己的ControllerFactory，

     ControllerBuilder.Current.SetControllerFactory(new UnityControllerFactory())

  d. 对Controller进行构造函数注入，例如：

      public class UserController : Controller

      {

           public UserController(IUserService, userService, IMessageService messageService)

           …

       }

    从现在开始，所有的Controller都是通过依赖注入框架来创建的，新增的Service就在依赖注入框架里面注册，Controller要使用哪些Service就往构造函数里加，反正框架会注入进来。

 

    第2点， 类如HttpContext.Current.Session[“xxx”] = …, HttpContext.Current.Cache.Insert…此样的代码充斥在各个角落。有问题吗？还是老问题，可测试性，可替换性。

    像HttpContext这种东西，几乎是不能Mock或者Stub的，只要代码中使用了HttpContext，可以说它就没法做单元测试。为什么很多人都会这么用呢，一个原因是图方便图简单，二是没有写单元测试。要用Session直接用就好了，封装一下再用多麻烦啊，这就是图简单。

    解法很简单，对HttpContext进行封装，例如ISessionProvider, ICacheProvider，然后通过依赖注入框架，注入到Controller中去，这样的结果是代码可测试性高，而且想改变Cache机制也很方便。

    意识不够。什么意识？让代码松耦合的意识。使用静态方法，静态变量，直接new依赖的对象，这些都是松耦合的反例。我们写代码的时候要规避它们。即使我们不用TDD（极端一点来说，现在不写单元测试），脑子里也要清楚记得，面向对象的法则、松耦合的一些原则等等，然后反应到代码上去。

    这一点，记得好像园子里以前有人提到过。

 

    最后一点，View中不写条件逻辑。View中一旦加入条件判断，就会使得代码特别难以维护，难以理解。如果在aspx文件中，看到以下的代码：

   <% if (条件1) { %>

    <div>

      …

      <% if(某某条件) { %>

       …

       <% } %>

     </div>

   <%} else if (条件2) { %>

      …

   <% } else { %>

      …

   <% } %>

   这样的View让人很怕去改，生怕哪里改错了而自己又不知道。因为它写的太混乱，逻辑和显示穿插在一起，如果再混着一些动态的html元素，那就真的只能谁写的谁来弄。

   我们可以怎样做呢？如果是比较复杂的条件逻辑，就放到Controller里面去做，然后返回不同的View。这样View又很简单，这些逻辑又可以被测试。没有谁规定，一个Action只能对应一个View。跟Class的道理一样，Class职责过多，就得进行拆分。View的逻辑过于复杂也得进行拆分。

  这么拆分以后，有可能会出现几个View有重复的部分。那就具体情况具体解决了，可以使用ViewHelper，也可以把重复的东西再独立出来，不同的View来复用。记住，View是代码的一部分，不要觉得涉及到Html的部分乱就乱点。View也是需要持续被重构的。

  这一篇着重强调的是，漂亮的代码有良好的可测试性。