CRUD全栈式编程架构之数据层的设计
CodeFirst
一直以来我们写应用的时候首先都是创建数据库
终于在orm支持codefirst之后，我们可以先建模。
通过模型去创建数据库，并且基于codefirst可以实现方便的
实现数据库迁移的工作.使用codefirst有以下几个技巧，
以EntityFramework为例,结合我这个设计做了以下改进
1.模型的识别
建立一个基类命名Entity，里面只有一个long类型的id字段。
所有需要映射到数据库的模型都继承自Entity,
2.模型的映射
选用fluntapi作为配置（可以保持模型类的整洁，并且和具体orm无关）
新建一个配置基类继承自EntityTypeConfiguration，并且添加泛型约束，
在构造函数中配置表名(和类名一致),和id作为主键，并且设置成由程序生成。
如果是一般单表的话，配合System.ComponentModel.DataAnnotations下的特性
即可完成数据库字段长度等等限制
3.模型的生成
重写DbContext的OnModelCreating方法，反射程序集所有需要映射的类型，
然后，查找对应配置，如果没有则构造出配置基类，即可完成模型的创建，
ef默认会在第一次访问的时候去创建或者校验模型，
模型的配置缓存在全局静态数据中。如果对应模型类有
Repository
关于Repository的文章很多，这里就不重复描述了。
我这里都是采用的接口编程，全部是采用构造函数来注入。
我这里需要为每个类型的CurdService注入一个默认Repository实现。
其他一些技术
UnitOfWork(工作单元)
网上文章也很多，简单来说，把若干个数据库操作放在一起作为事务提交
得益于ef的设计，ef使用dbcontext.savechanges()方法等价于unitofwork.commit()方法
这部分的设计主要借鉴NLayerApp.
如果没有ef我建议是把每一个增删改类型的sql命令做成委托，然后左后commit的时候
使用事务提交。代码如下
Specification(规约)
同样网上的文章也很多，我这里只是把他作为查询实体来使用.
如果使用传统ado.net的方式，直接传表达式到Repository中的话
将导致解析表达式特别复杂，而用Specification的话，相当于查询
语句中的where部分由它来接管，这样解耦和Repository和具体orm的依赖
这部分的设计主要借鉴NLayerApp
多排序
在分页中我们经常遇到多查询的情况，核心就是构造表达式，等同于构造
sql语句中orderby的部分，同时它也支持内存中的多排序
这部分设计主要借鉴Apworks中多排序的设计
Ps:
比较零碎，如果有什么问题可以在下面给我留言。
其中模型创建代码中有一个_context.这个属于下个系列内容。
主要用来搭配模块化做业务垂直分库用.
重点是看设计思路，代码只是给一个演示，一般照搬是编译不过的.
文章系列的结尾会放出一个完整的设计代码和一个简单的示例.