架构设计：数据访问层简述

在前面简单描述了下服务层，SOA面向服务架构，架构设计-业务逻辑层，以及一些面向设计原则理解和软件架构设计箴言。这篇博客咱们将继续进入咱们的下一层：数据访问层。不管你用的是什么开发模式或者是业务模式，到最后最必须具备持久化机制，持久化到持久化介质，并能对数据进行读取和写入CRUD。这就是数据访问层。你多是利用xml等文件格式磁盘存储，经常使用的关系数据库存储，或者NoSql(not only sql)的内存存储或文档存储等等存储介质。而这里我只关心关系数据库存储。

数据层须要提供的职责有：

1：CRUD服务。做为惟一能够与存储介质交互的中间层出现，负责业务对象的增长，修改，删除，加载。

2：查询服务。这不一样于CRUD中的R（read），read倾向于的单个对象，元组。而这里的查询针对复杂查询，好比一个国内电商的客户为四川的订单。这里会涉及仓储层。所谓仓储模式指的是一个提供业务对象查询的类，他隐藏了数据查询的解析步骤，封装sql解析逻辑。

3：事务管理。这里所说的是业务事务，在一个应用系统中每次请求都会产生屡次的多数据对象的新增，修改，删除操做。若是咱们每次都依次代开数据库链接，准备数据包，操做数据库，关闭数据链接。这些将会给咱们带来不少没必要要的性能开销。数据库管理员常常会要求“尽可能少的与数据库交互”，这也必须成为咱们的开发原则。更好的操做是咱们在内存中创建一个和数据仓库，维护变化的对象，在业务操做完成一次性提交到数据存储介质，提供业务事务。业务事务有个很好听的名字工做单元（UOW），在微软给咱们提供的DataSet，orm框架都回必须存在业务事务。

4：并发处理。UOW应避免业务数据链接的屡次提交打开而出现，但在内存离线操做，这就可能致使数据一致性问题。在多用户的环境，对数据并发处理须要制定一个策略。通常咱们会采用乐观并发处理：用户能够任意的离线修改，在修改更新时候检查对象是否被修改，若是被修改者本次更新失败。简单的说就是防止丢失修改。防止丢失修改，咱们能够采用where 加上一系列原值，或者加上修改时间戳或者版本号标记。同时还有许多其余的并发解决模式，但乐观并发锁用到更广泛。

5：数据上下文：整和全部职责。在数据访问层概念职责都会有一个共同的暴露给外部的接口。咱们须要一个高层次的组件，来同一提供对数据存储介质的访问操做。，同一访问数据库CRUD，事务，并发服务的高层次类，叫作数据上下文（Context）。EF中的ObjectContext，NHibernate的session，linq to sql 的DataContext等等。

数据访问层的一些概念（这里不会是所有，仅一些我的以为重要的概念）：

1：数据映射器：将内存中修改的对象提交至存储介质，则须要要映射逻辑来完成，数据映射器就是就是一个实现将某种类型的业务对象持久化的类（数据映射器模式定义如《P of EAA》）。

2：仓储层（Repository）：在上面提到：所谓仓储模式指的是一个提供业务对象查询的类，他隐藏了数据查询的解析步骤，封装sql解析逻辑。在面向对象的世界里咱们用对象进行查询，返回结果为对象集。这里的查询多是从数据库，或者来至缓存，这取决你的策略，你仓储层的实现。

3:工做单元（UOW）：Martin Fowler《P of EAA》定义：工做单元记录在业务事务过程当中对数据库有影响的全部变化。操做结束后，做为一种结果，工做单元了解全部须要对数据库作的改变。在上面第3点业务事务讲的差很少，这里不是累述。

4：标示映射（Identity Map）：其做用在于：便于跟踪业务对象，调用者在一个业务事务中使用的是同一个实例，而不是每次执行产生一个新的对象。表示映射为一个散列表存储（散列具备快速定位O(1)）。相似于缓存的实现方式，保证了在同一个业务事务数据上下文引用修改同一个业务对象。但毫不同于缓存。从持续时间来讲，标示映射生命周期为业务事务内。实现上等同于数据上下文期。但比起缓存来讲其周期过短，根本不能对性能有多大的改善。缓存更重要的命中率，而标示映射保证同一数据上下文采用修改同一个业务对象的引用。

5：乐观并发锁：在上面也曾提到，其保证离线操做数据的对数据一致性的冲突解决方法。首先乐观在于容许离线操做，容忍冲突，防止数据丢失修改，可利用原读取数据值得where条件或者时间戳，版本号解决。

6：延时加载：对象并非一次性加载完成，而是按照需求屡次加载数据，到用时加载。业务对象太多关联，数据量太多余庞大，而咱们每次业务事务须要操做的对象都只会是部分，不须要太多的数据对象。同事业务对象中还存在循环引用，这样不适于对象总体的一次性加载。延时加载提供了优化，意图在“尽量的少加载，并按需加载，只加载须要的数据部分”。

7：持久化透明对象（PI或POCO）：当对象模型不存在任何外部依赖，特别是对于数据访问层的依赖，那么这个模型就是持久化透明的，POCO。一个POCO的对象不须要继承至某个特定的类，实现特定的接口，或提供专门的构造函数。一个非持久化透明的对象这觉得者存在外部的依赖，而咱们更喜欢领域对象只是一个简单额c#类，能够在持久化层等独立切换。这就致使实现的时候咱们没法很直接的跟踪业务对象，这就是面向方面编程（AOP）或者代理模式的大显身手。惋惜AOP在.net中不是那么直接，不少ORM框架如NHibernate之类的利用代理模式Emit动态注入IL实现跟踪，添加新的行为。因此NHibernate中要求领域对象的全部字段属性方法都必须是虚方法可重写的。:

8：CQRS（Command Query Responsibility Segregation，命令查询职责分离）：CQRS是在DDD的实践中引入CQS理论而出现的一种体系结构模式，命令和查询被分离。

连接：https://pan.baidu.com/s/1v5gm7n0L7TGyejCmQrMh2g 提取码：x2p5

免费分享，可是X度限制严重，如若连接失效点击连接或搜索加群 群号744933466。