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.这个属于下个系列内容。
      主要用来搭配模块化做业务垂直分库用.
　　重点是看设计思路，代码只是给一个演示，一般照搬是编译不过的.
      文章系列的结尾会放出一个完整的设计代码和一个简单的示例.

分类: CRUD全栈式编程架构