Unity 在MVC上的应用(下:ORM)

系列目录

  Unity 在MVC上的应用(上:思路整理)

  Unity 在MVC上的应用(中:Repository)

  Unity 在MVC上的应用(下:ORM)

  Unity 在MVC上的应用(扩展篇:JQuery AJAX)

  Unity 在MVC上的应用(扩展篇:事务控制-前篇ActionFilter)

  Unity 在MVC上的应用(扩展篇:事务控制-后篇Unit Of Work)

  Unity 在MVC上的应用(扩展篇:日志管理NLog)

技术点应用

   1.ASP.NET MVC3 (新东西绝对要用用XD)

   2.引入IOC容器：Unity(非XML配置方式)

   3.使用NHibernate 3.0(支持LINQ)和Fluent NHibernate(简化NH配置难度)

   4.加入Service接口再结合ViewModel定义层数据协议(实现表现层和业务层分离，各司其职)

正题

　　回顾上两篇文章，我们发现根本没有Unity的踪影，汗颜，写着写着发觉进度太慢，都没用上的场合，但这篇文章会加入Unity来少SHOW一下用法，主要是来个抛砖引玉。

     这次项目由于想用MVC3来做，所以就直接开一个新的项目来展示了，放弃之前那个了，从需求到实现全过程慢慢回放，(*^__^*) 嘻嘻……，虽然简单，但会很流畅，具有回溯性。

作为经常开发软件的程序员，总所周知，未登录的用户功能模块是最常见的模块之一，我们就从未登录用户模块入手来设计吧，由于名字太长，我习惯把它叫做游客模块。废话少说，我们先看看这次项目的总体结构图。

几个类库，和一个WEB。简单解析一下各个类库的作用。Domain用来存放实体对象，而Infrastructure是提供一些框架基础功能，Service是对外提供的应用服务，ServiceConcrete是Service服务的具体实现，UnitTest是单元测试用的，ViewModel是表现层的数据载体，Web就不用我墨迹了。XD

刚提到从需求入手，常见的游客模块功能有登陆(LoginOn), 注册(Register),找回密码(FindBackPasswrod)等功能。多的就不细想了，主要是做一个需求参考，所以根据这些动宾结构的文字需求我们可以得出一个游客管理接口，如下图。

也许你会觉得奇怪，为什么会有这么多奇怪参数和返回值，这里是因为我用到了ViewModel充当DTO，意图是给表现层定义一批针对UI的数据协议，绝对分离表现层和业务层的关系，因为很多时候一个视觉看到的东西并不等于业务对象的所有信息，有可能是业务对象的一个子集，也有可能是多个业务对象的并集，面对如此不稳定的UI视觉效果，我们应该为它定义出一套属于它理解的模型，这样面对UI的变化就会安逸很多了，如果你习惯把一些简单类型作为方法参数，你就应该去重新定位你对层的理解，当然不否定简单类型作为参数有时候是存在，但我的经验告诉我，很多时候都不应该这么草率去使用简单类型作为一个功能参数，至于为什么，真的是一言难尽~XD 我们顺带看看ViewModel的布局

我是根据模块-功能来分类的，命名方式十分不优雅，我也想不到更好的分类和命名方式了，如果你有更好的解决方式，可以告诉我。而注意的是，DTO开头的模型在这里的意思是输入型数据模型，而VO开头的是展示型数据模型。因为我所理解的数据协议包含了输入协议和输出协议，虽然不一定并存，但一定会存其中一者，如果都不存在，就不会产生交互的需求了。XD

我们来看看Infrastructure的结构

因为我这里是用到NHibernate 作为ORM框架，所以很多处理都是围绕NH。我们先回顾一下上篇提到的IRepository接口

不再详细解释其功能了。再来看看一个INHConfiguration，NHibernate配置接口，其意图是隔离配置方式，因为我这里是用Fluent去配置的，有时候想用XML，所以~

我们再看看具体的配置实现

因为这里是使用到Fluent NHibernate的配置，所以知识点请没学过的朋友自己查阅，不过从图中可以看出，配置的方式很直观，这里不详细解释用法，而使用Fluent的目的很简单，我坚信“约定大约配置”这一道理，而且有静态语言的代码智能检测功能，犯错更从容~XD。PS:数据库自动生成的，不用你手动去建数据库的。

再转回来看看NHibernateHelper这个辅助类

这里不解释了，园子里都有很多文章介绍过。

看看我们具体的Repository实现类。

有部分用到NHibernate.Linq~然后我们关注一下我们的业务对象，虽然只有一个，，暂时的一个XD 然而这个User实体对象，是从多个用户数据模型场景精化而来的，不是无中生有也不是拍脑袋的产物，它的属性是从前面多个User ViewModel的属性交集得出来的。

还有它的映射文件，也是用了Fluent的后果，不用再写XML的映射文件了，个人觉得比较清爽和飘逸。

值得注意是，这里有一个Entity，主要作用是，复用对象标示，减少重复代码，虽然代码量不多XD，不过不提升成父类就太那个了！！

转回来，我们看看具体的Service实现类，暂时只粗粗实现了一个功能，XD，由于时间关系，多多包含，(*^__^*) 嘻嘻……没实现的我就打格仔了。

实现逻辑写得比较简单，或许有不当之处~请不要拍板XD

功能模块和基础模块都做好了，当然Controller和View都自动出来了

说了这么久还没看见Unity，想必你都和我急了，说实话就快到尾声了~哈哈

这个IDendencyResolve是MVC3特有的，和以前重写ControllerFactory一样，都是为了可以方便对Controller实现依赖注入。

而我们的Unity当然是在Global文件上调用啦。

 

 只需要用RegisterType注册一下对应的接口类型和实现类型，就可以实现依赖注入的效果，可以发现，基本上全程都没出现 new对象，其实有一个地方出现了，(*^__^*) 嘻嘻……。总体来说使用IOC的初衷达到了，所有框架应用都不存在以往使用XML文件繁琐的配置方式，个人感觉良好。

本篇结语

希望这篇博文对你有所启发，而三篇系列就这样结束了，再这之后，我打算继续开一些扩展篇来围绕今次这个个DEMO来展开，加入一些实际开发中常见的问题的处理方式，如事务处理，权限控制，登陆状态检测，前端技术等等，下篇将会介绍一下JQuery AJAX在MVC上的应用~敬请期待。