其实，我也是开发人员，这框架是我一个字母一个字母敲出来的，能偷懒的我肯定都会偷懒！就像前面我没采用Repository一样，我甚至都还弄过两层架构，但最后都没有好下场，才一步步走到今天。简单的说，ViewModel存在的原因主要有两个：

第一、前后端分离的要求。如果直接使用Entity，前台开发人员是不是又得等着后台开发人员把Entity先建好？是不是Entity一有变动就会立马影响前台开发？有兴趣的同学可以观察我们的ui.task.zyfei.net.sln解决方案，BLL层里的所有project是根本就没有包括在里面的，我们彻底的做到了物理隔绝！

第二、ViewModel和Entity其实是不能100%对应的。尝试过的同学都应该明白。比如我们创业家园项目里有“最新发布博客”的列表小方块，它是一个博客的集合，你怎么弄？你说我可以使用IList<Blog>；但这个小方块里还有一个逻辑：如果当前用户是博客博主，显示修改链接。所以需要“当前用户”的数据，你又怎么把这个数据弄进来？当然，这是一个很大的命题。你肯定可以通过各种手段做到，最简单的就是使用ViewBag。混合ViewBag和Enitty，几乎可以解决所有问题，但有时候太丑陋了！

最后，我们其实应该跳出来，从架构的角度来思考这个问题。ViewModel究竟是什么？它说承载的职责应该是什么？应该由谁来构建它？……

我认为：ViewModel本质上就是一个用于页面呈现的数据容器（DTO），所以他不应该具有任何内在逻辑，而且应该由前端开发人员来构建它。前端开发人员应该彻底的摆脱业务层中的Entity的束缚，根据页面的呈现规律，大胆的进行各种抽象组合，使得ViewModel真正的绽放它的光彩！

MVC

说完了上面这些，MVC其实也就没什么好说的了。就是Controller调用Service，得到ViewModel供View使用这样一个流程。当然，里面有很多值得细讲的内容，比如mvc route的测试、使用Autofac切换Service的实现、Session Per Request进行性能优化等。我们在之后的分则里细讲。

这里还是上一张我制作的PPT吧，丑了点，先将就看吧！

Tool

看过源代码的同学肯定也注意到了项目里有一个Tool的项目文件夹。里面最重要的，就是BuildDatabase项目。这个项目，肩负了构建开发和集成测试数据库的双重责任，还有帮助生成环境数据库更新的作用，是测试驱动的有力保证。可参考（文档可测试化）

要填的坑

框架就这么拉出来了，但其实里面的坑还有很多，趁着有思路，先挖出来，以后慢慢填：

1. UI

2. Service

3. BLL

4. Tool

呵呵，原来有这么多坑！

这又让我不由得想起我烦躁咆哮，扯头发摔鼠标的那些日日夜夜，我也不止一次的怀疑过，我是不是走错道了？这些乱七八糟的MVC、测试驱动、面向对象……根本就没有让我更高效顺畅的开发，好像只是不断的在扯我的后腿。我就用传统的办法，拖控件增删改查数据库又怎么啦？不是一样能用？而且说不定早就开发完了！……

但一次又一次解决问题的喜悦，一不小心窥视到另一个世界的惊奇，让我欲罢不能。这可能就是技术路，人生路，大抵也如此吧？

最近沉溺于知乎，耽搁了正事。实在是惭愧啊！无论如何，从本篇博客开始，我又回来了！回来继续苦逼的填坑……