公司最近在做一些技术培训，其中有关于MVC方面的介绍。刚好BOSS给我安排了这方面的内容。其实我本身对MVC也是一知半解，只是知道微软有一个MVC的经典范例，把一个Web应用拆解为抽象层(AbstractLayer)，实做层(InplamentLayer)，数据访问层(DataLayer)，业务逻辑层(BusinessLayer)和呈现层(PresentationLayer)几个层。于是我就着微软的范例给PG介绍关于MVC方面的一些概念。
其中的呈现层、业务逻辑层、数据访问层都是比较好理解的概念，但是当我介绍到抽象层和实做层的时候，有PG提出疑问说为什么要把这两层拆分呢，放在一起似乎也没有太大的问题呀。
的确在我们常见的Web开发中(例如普通的用户系统、新闻发布系统)把这两者直接放到一起并不会出现什么问题。但是如果仔细思考一下，我们就会发现其实这两层还是拆分开会比较容易维护。
例如我现在给大家说这样一个例子，学校里面有很多老师，有的负责教授语文，有的负责教授数学，有的负责教授计算机理论，有指导计算机上机操作还有一些根本不上课，只是负责安排学生生活的教师。很明显，所有这些教师的信息会存放在同一个教师信息数据表中，同为教师，大家的属性都是相同的。于是根据这个表，我们会映射成一个教师类，会有姓名，性别，年龄，教授科目之类的各种属性，对于这个类，各类教师都是相同的。然后教师类还需要定义一些方法来对应教师的工作，我们假定这个方法名就是Work。如果我们把该方法直接放到教师类里面(也就是把抽象层和实做层合并在一起)这时候问题就来了，负责不同工作的教师需要定义不同的内容的Work类，例如语文老师需要在Work里面进行语文授课，负责上机操作的老师需要在Work里面进行硬件设备和操作系统讲解而负责学生生活的教师则可能需要在Work方法里面完成检查卫生之类的工作。
也许大家会说这不要紧，只要根据教师的教授科目(或者负责工作内容)这个字段(Column)来进行判断，然后多几个If...Else...就OK了。的确如此，可是如果新增了教师教授科目该怎么办呢？不停的修改Work方法么？显然这是不合理的，这时候如果我们能把抽象层和实做层拆开，就很好办了。抽象层里只有与数据表的字段对应的属性，而具体类的方法都在实做层进行定义。这时我们就可以为每一个不同的教授科目老师定义不同的实做类。语文老师一个，数学老师一个.......等等，每个实做层的类里面都有一个对应的Work方法。当需要某个老师工作的时候就实例化一个对应的教师的实做类，然后执行类似于 数学老师A.Work() 或者 语文老师B.Work() 这样就可以让对应的老师干他们自己的工作了。而当有新种类的授课老师加入的时候，只需要从抽象层的教师类派生出一个实做层的科目教师类，然后定义对应的Work方法就满足需要了，并不修要去修改已经现存的类。
如上的解释希望能给初入PG的朋友在学习多层架构的时候一点帮助。当然实际开发中的逻辑会比这个例子复杂得多，我说这个简单的例子只是为了解释为什么需要把抽象层和实做层进行分离。有不妥的地方还请指正。
