/// 为什么是NHibernate？ /// 1、我的项目开始得比较早，好几年前了，应该是。当时Entity Framework还很不成熟，所以没有办法，只能选择NHibernate /// 2、我想看一看微软框架以外的世界。其实后来我就知道了，在Java世界，我的这些做法已经差不多是主流了，所谓的SSH之类的。当然，对Java世界我也研究不深，可能也有差异。我的这个框架是自己摸索出来的，觉得够用就好。

但从系统架构层面讲，有另外一种提法：Repository模式。

Repository，从字面意义上理解，就是仓库。这个概念我觉得很贴切，就像汽车存放在库房里，我们通过仓库管理员，取出一辆或多辆汽车。这就有“代码映射真实世界”，一种逻辑自洽的感觉；而不是之前，一辆汽车取出十辆汽车的样子。

具体到代码层面，就大概是这个样子：

class BlogRepository { IList<Blog> GetBlogs(int pageIndex, int pageSize) { return new List<Blog>() { }; } Blog Get(int Id) { return new Blog(); } }

但Repository的理解和使用都有争议，主流的大概有两种：

我连Repository都没有显式的使用，所以就不进行这种关于概念的抽象讨论了。后面有机会我们穿插着讲一讲吧。

我们“增”和“删”直接利用了NHibernate的session机制，只是把“查（select）”给单独抽象了出来，也单独的抽象成一个名为Query的project。

Service

好了，现在我们可以回头归纳一下。对系统数据的操作，我们脑海中应该是这样一个概念：

那么问题来了，上面这些步骤，由“谁”来做呢？注意我们现在所说的这些东西，都是在业务层的范畴。所以，按照三层架构的思路，应该是UI层调用BLL层，而我们的UI层，采用的是MVC，所以，这样工作，是不是应该在Controller里面做？

但是，阅读我们的源代码，你就会发现，我们在UI层和BLL层之间加了一个Service层。实际上是由Service层来做的这些加载、修改和存储的工作。我非常同意这么一个观点：绝不能为了分层而分层。那么，Service层存在的意义是什么？

主要是为了前后端分离。早期的开发过程中，我设想过招聘一个专门的前端开发人员，他/她不管后台的具体业务逻辑、和数据库的交互，只管页面的呈现和交互。那么这里就有一个问题，我不想她只是一个单纯的美工，画出效果图切片弄成一个html的静态页面就完了，我希望她一样的用VS进行开发，用Razor做成view，还负责页面的交互和跳转，所以她还得在Controller里建Action，在Action里写代码。所以她在Action里写代码，是要得到数据用以呈现的，是需要根据页面回发的数据调用不同的业务逻辑的。那么，这些数据这些调用怎么得来？等着后台开发人员完成了之后再做？这无疑是很不经济的。

所以我们抽象了一个ServiceInterface，前台和后台开发人员可以先确立一系列的接口，然后各自去完成自己的实现。于是就有了：

这其实就有一点“面向接口”的意思，前台后台都依赖于ServiceInterface的接口，而不管其具体的实现。

// 从这里我们就可以看出来，复杂的架构是一种无奈的选择。 // 如果我们的所有开发人员都是全栈级别的，可以从效果图一直插到数据库，我们可能就根本不需要这么麻烦。 // 而现实的情况是，而大部分的开发人员，都有他们的专攻方向；全栈程序员毕竟太少了。

当然，这样隔离出UIDevService之后，还附带了其他一些好处，比如更便利的单元测试。这些我们都以后再说。

上张图吧。先看看，看不懂也就算了，实在是我画得不咋的。以后还会详细讲的：

ViewModel

我们项目中还有一个ViewModel，我们的开发人员曾不止一次的提出来：为什么不能直接使用Entity呢？

我非常理解他的疑惑，一次次的把一个Entity里面的Article的属性取出来，再一条条的放到一个ArticleViewModel里面去，这多闹心啊？吃饱了撑的？