数据访问层的职责

 

    数据库的独立性

    数据库独立性的含义是无论最终数据存储的介质是什么，数据访问层都要能够为系统的其他部分提供相同的服务，例如，创建，读取，更新，修改，事务性和查询等。若你的模型中包含一个名为Customer的对象，那么数据访问层要能够将其存放在不同的存储介质中，例如，SQLServer或Oracle。数据访问层将对业务层隐藏此细节。

    那么我们如何实现数据库的独立性呢？通常来说，数据库的独立性需要使用一套通用的，跨数据库的应用程序接口。当业务层获取到当前数据访问层的引用之后，业务层以多态的形式，通过公开接口的方法与数据库进行通信。我们可以在配置文件中切换数据库。

    还有一种方法也可以实现数据库的独立性，就是使用ORM关系映射工具。他会提供一套公共的API，让你只需修改配置文件即可切换到不同的数据库。

 

    数据访问层的职责

    数据访问层对其使用者来说有4个职责。首先，数据访问层需要将数据持久化到物理存储中，并为外界提供CRUD操作。

    其次数据访问层还能处理接受所有数据相关请求，数据访问层必须满足事务性的需求。最后，数据访问层也要合理地处理并发问题。

    1.CRUD服务

    CRUD服务是一系列的方法，负责将对象保存至关系型数据表，或从关系型数据表中读取数据并加载至新创建的应用程领域模型的类型实例。

    应该为实现CRUD服务编写怎样的代码呢？对于对象模型的每个类型，我们都要为其创建一个映射类，并实现一个接口。该接口中给出了该类型上所有数据库的相关操作。映射类内部可以使用ADO.NET或Linq To SQL来具体的实现。

    2.查询服务

    在某些情况下，我们会需要处理很复杂的查询，而且也不是所有查询都是一样的。有时我们会提取出一些通用的查询，在业务层和服务层的多个位置使用。

    更好的做法是将所有的硬编码，在业务层被多次使用的查询定义在仓储类中。此外，再定义一个通用的查询对象，能够以编程的方式配置并在执行时生成所需要的SQL代码。

    该查询对象的主要目的是通过对象的各个属性和方法收集数据，然后为数据库动态生成所需要的SQL代码。

    查询条件属于查询对象模式的应用，根据该模式，查询对象将定义成类，并包含一系列查询条件的集合。查询条件是一个简单的类，包含一个属性名，一个值，一个逻辑操作符，用来表明属性名和值之间的关系。

    

 

    3.事务管理

    在一个设计良好的数据访问层中，应该有一种机制跟踪一个工作单元内对应用程序数据的所有修改，这样即可在稍后将这些修改一次性地持久化到数据库中保存。这个工作单元就是一个逻辑上的事务，它包括一系列的数据库调用。

    所以我们应该创建一个能够维护发生变化的领域对象列表的类。这个类同时也提供了事务的语义（开始，提交，回滚），配合数据库的物理事务将修改提交回数据库。

    4.处理并发

    所以我们应在一个多用户环境中，与数据库离线操作会导致数据完整性的问题。用户A加载了产品1234的一个拷贝并更新了其描述，因为该操作属于一个较长的事务，我们可以假设该修改并没有立即提交。而同时，假设B也加载了1234的另一个拷贝，并更新了产品图片的URL。若用户B立即提交了它的修改，那么当用户A提交产品修改时，系统又该如何应对呢？

    你获取会说“这没问题呀”，因为两个用户更新了不同的字段。不过若是两个用户修改了相同的字段又该如何呢？很有可能第一个用户对产品的修改就这样丢失了，这通常叫做“最后写入者获胜”。

    乐观的并发处理意味着用户可以自由地尝试更新数据库中的任意记录，不过成功与否不能保证。若数据访问层发现即将要更新的记录已经被别人修改过，那么此次修改失败。

    5.整合所有职责：数据上下文

    简而言之，你需要一个更高层次的类，用来表示并引导与底层存储介质的交互工作。随后，数据访问层的使用者就可以用该高层次的类作为存储介质的统一操作位置。ORM都有此高层次的类。

    这个可以统一访问数据访问层及其CRUD，事务和并发服务的高层次类通常叫做数据上下文（DataContext）。

    

以上内容来自《Microsoft .NET企业级应用架构设计》