三层开发方法洪流下被QJ的MVC

    首先大家看到这个标题一定会产生一个想法，这是什么跟什么啊，先且不说大家对“QJ”一词的理解，就说三层和MVC本来最初被大家误认的东西到现在大家都明白的一个东西，他们怎么会被扯到一起？MVC不能代替三层，三层也并不能代替MVC啊！你连三层和MVC的本质都没搞明白，还在这里乱说。其实这里我只是稍标题党一下，由这个标题引发一的场沉思。

 

1、 三层的由来？三层为何像凤姐一样如此之火？

首先，想必大家最熟悉的也是最长用的就是三层“开发方法”了吧，无论懂的与不懂的，大街小巷。以至于一些软件培训机构都把三层做为面试必修课，无论是真懂还是假懂都能说出个“所以然”来。三层形式真是一片大好啊。回头想想三层为何如此之火，这就要说到PetShop来了，微软当初推出PetShop真是个明智之举，这么个东西对推动.NET发展真是起到了非常大的作用，他告诉了大家我.NET是怎么样可以做企业开发，怎么样标准的。同时他最大的功劳就是“标准化了大家的开发模式，对技术流通起到了很正面的作用”。同时也产生了一定的问题，就是大多数人只认三层了（当然这里暂且不说三层的好与坏）。

 

2、 MVC模式

随着asp.net mvc框架的推出，在.NET社区引发了一场MVC热。一时间大家对webform充满了敌意，唯mvc是从。当然这不是说MVC不好。说到MVC，中文解释就是Model(模型)，View(视图)，Controller(控制器)。View和Controller是用来做View的，实现表现元素与表现逻辑的分离，那M职责是什么呢？问题的点就在这里了，我发现好多人的项目M都是空置的。当然，这里有一点是我们的业务很复杂、我们需要抽离出单独的分层。这是一点，还有一点就是，“我不知道M里面应该放什么”，我之前所熟知的三层，Model都是失血的， 显然放在这里不合适。而业务“对象”的呢？我们是事务典型的事务脚本模式，显然放到这里也不合适。所以我认为这个M是多余的，我大多数做是需要Controller调用Biz(业务层)就可以了，至于MVC的M完全没有他的事情了。那我们回过头来看MVC,为何他要做MVC,而不是VC呢？这样不更是符合他做为View模式的身份吗？在我看来MVC出发点不是事务脚本模式的，而是领域模式或是Active Record的，M应该是自包含逻辑的。当然这里DDD太过于庞杂，放到这里显然也不是非常的合适，剩下的最适合的就是活动记录了，MVC配合活动记录模式用来做WEB应用，比如论坛博客再合适不过了。

 

本来的第3点，写到一半的时候我的思想乱了，完全失去了文章开头的中心思想，突然觉得越写越不知道自己写的是什么，但是又写这么多了。不发可惜了。

 

如果我看到这样一篇文章，我肯定回复就是：

1、 不知楼主所云

2、 标题党

3、 #&%）（%）（#）@#（￥&#@）￥