NHIBERNATE的简单框架的设计

NHIBERNATE的简单框架的设计

上次的 NHibernate的Session管理策略和NHibernateHelper 发布并提供下载，给NHibernate刚入门的同学们带来很多便利。

最近有同学在求NH的通用仓储，正好我最近也设计了一个应用于实战，好吧，无私地分享并快乐着吧。

与上次一样，您无需关心细节，因为我会在最后提供源代码的下载。

如果您对ORM没兴趣，或者觉得此文看标题与大多数文章类似的话，为不浪费您宝贵的时间，请点又上角红叉。

Repository设计

从整体上可以看到，这个仓储用到了泛型，并且继承了一个叫BaseRepository。

BaseRepository的作用就是为仓储提供一个特定的Session上下文，以便仓储中使用和执行事务。

（这里提供的上下文都是NH自带的一些功能，并没有做扩展。有兴趣玩更复杂的，请关注我的数据访问层设计。）

你会看到这个仓储除了有普通的增删改的行为以外，还提供了一系列的查询，

这是为了在具体仓储中可以少写一些代码，另外这些行为都比较细，是为了在业务层重新组装成业务组件来使用，比如分页组件。

细心的朋友可能会发现了一个函数（TranslateQuery），它是用来将Query对象翻译成NH的条件查询，因为我尽可能地做到HQL或SQL不出现在数据访问层之外。

（可以将这个翻译函数改写成翻译成HQL）

在BaseRepository中就使用到了上一节中的Session管理策略，不再详细解说。

仓储实战

这是一个仓储的例子，可以看到刚才函数的设计的确帮助我们减少了代码（this.GetCount）。

这里的调用可以看到将HQL移到了仓储内，保持逻辑清晰。

分页组件

分页组件的实现非常简单，因为前面仓储已经做好了铺垫，明确地说，这个分页组件不在仓储，而是组织仓储功能。

因为作者认为有些分页需要返回一个总记录数，这个其实是特定的分页插件需要考虑的，而仓储不应该知道UI插件的存在而专门为一个UI插件提供功能。

你会发现GetCount函数并没有白白准备，而实战中关联对象的List<T>.Count可能会做一次延迟加载的查询，所以这个函数必不可少。

分页的实战

条件查询

排序

事务管理和Repository的重用考虑

我们通常会在领域模型Service中组织仓储，供更上层的调用，而在仓储中控制事务的打开和提交，明显会阻碍仓储在业务层被重用。

解决的思路可以看我的业务逻辑层设计——事务的考虑，下面我给出一个简单的做法。

看了以后你会发现事务中间的代码非常简单，其实复杂的逻辑早已被封装在这个order对象里面，有兴趣研究的同学可以参考我的业务逻辑层设计和示例代码。

这里使用BaseService自己封装的事务控制，而没有使用Spring.NET，因为我不想再为了减少代码而转移到XML配置文件，保持简单和学习成本。

花絮

这个项目本来是基于.NET2.0的，所以我并没有打算给他升级，所以NH版本选择了2.1，也就没有Linq， 也就没有fluent。

设计过程当中到了很多阻碍，EasyUI也只是点到为止Grid没用，展示层使用MVP模式被抱怨代码难以理解，

作为架构师应该推荐好的技术和框架向社区、公司或同事，可以看到这个本版移除了Spring.NET，没有采用微软企业库，这算是一种对公司的妥协。

好了，就到这里，英语真的在催我了，我先去了。

参考过很多书籍和博客

感谢博客园前辈们

李永京、弦哥、刘冬.NET、博客园NHibernate专题。

参考书籍

《Microsoft .NET企业级应用架构设计》

《领域驱动设计》

附件下载

NHibernateDemo

 

 

分类: 架构设计

标签: NHibernate, 架构设计, 领域驱动设计