[Unity3D技术之在MVC上的应用下.ORM.docxVIP

? 这次项目由于想用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对象，其实有一个地方出现了，(*^__^*) 嘻嘻……。总