本文内容
- 什么是持久层
- 为什么要持久层
- 持久层框架
什么是持久层
理解持久层，可以看它的英文——Persistence Layer。“持久（Persistence）”和“层（Layer）”。在我看来，“持久”更多涉及的是底层结构，而“层”更多涉及的是逻辑层面、软件设计。
在计算机早期，数据的存储只能在内存里，没有外部介质可以长期保持数据或代码，因此不能在需要时读取或是执行。看看现在，你几百个G的硬盘上都是什么，各种软件、各种照片、各种MP3……再看看数据库领域，如何存储、持久化海量数据，不仅要持久化数据，而且还要组织它们。这就是持久（化）。
“层”是什么概念？既然数据已经被持久化到介质上（无论这个介质是什么，磁盘也好，文件也罢，毕竟我们经过文件形式的数据库），那接下来的问题，也是最终问题：应用程序如何使用这些数据？通常采用三层架构的应用程序——表现层、业务逻辑层和数据库访问层。让业务逻辑层直接访问数据库库层，或是在业务逻辑层与数据库层之间再增加一层——持久层，让持久层去访问数据库层，而业务逻辑层访问持久层。这样，将数据的使用（业务逻辑层）与数据的实体（数据库）分离。
增加持久层的好处，在我看来，如果操作数据库的数据，就像操作程序中的类（类的属性）一样，那就再方便不过了。
为什么要持久层
先简单说明一下三层架构和它们的职责。在典型的三层架构中，对其职责的划分并没有一个统一的规范，综合现有的成功实践和 .NET 平台的特点，将三层架构的职责划分如下：
- 数据访问层——负责与数据源（数据库）的交互，即数据的增删改和查询。不负责验证数据的正确性和有效性，不负责业务逻辑。无需知道数据的用途。
- 业务逻辑层——负责系统领域业务的处理，如逻辑性数据的生成、处理及转换。负责验证输入数据的正确性和有效性，不负责验证输出的数据（如用户数据）；不负责数据的呈现。
- 表示层——负责接收用户的输入、并将输出呈现给用户以及访问安全性验证。负责验证输入和输出数据的正确性和有效性，呈现（式样）；不负责在发生错误时的异常。
总而言之，表示层负责输入数据的验证，以及输出数据的验证，因为要呈现数据给用户；业务逻辑层只负责处理业务数据，并在发生错误时抛出异常信息；数据库层只负责提供数据，供业务逻辑层使用。
虽说业务逻辑层不负责输入数据的验证（也就是说，不应该承担过重的数据验证功能），因为这个应该在表示层完成，但也应该至少提供基本的验证，比如如果输入为空（长度为0）、NULL等等，则执行业务，否则直接返回。数据库层亦然。
场景
假设有这样的需求，分页显示文章列表：
- 显示文章的标题、作者和发布时间。
- 如果文章标题超过15个汉字，则截断显示，以“…”表示。
- 如果是作者本人，则需在文章后边显示“编辑”和“删除”按钮。
接下来的问题是——在三层层架构中，如何各自的分配职责？
分析
- 对于需求1，业务对象应该返回给表现层一个文章的实体对象。文章的实体对象是一个集合的数据结构，这个对象有很多实现，比如 DataTable，json，ArrayList，甚至XML等等。
- 文章的实体对象至少应该包含“文章标题”、“作者”、“发布时间”等信息。文章的实体对象可以包含“作者”的详细信息（注册信息），也可以只是简单的信息。
- 对于需求2，仅仅是需求1的显示问题，与数据本身毫无关系。
- 对于需求3，要知道文章是否属于当前用户。这要根据文章实体对象中的“作者”信息，与 session["username"] 进行判断。
职责分配
- 分配给业务逻辑层
文章的列表，无论是默认的显示，还是有条件的显示，业务逻辑层应该根据用户需求，从数据库中返回相应的文章列表，并形成一定的数据结构。
- 分配给数据库访问层
仅仅是根据业务逻辑层的需求，从数据库中返回相应的文章列表。
- 分配给表现层
表现层应该根据业务逻辑层返回的文章列表，完成数据呈现，包括显示文章标题、作者和发布时间，以及文章标题的截取。
对于需求3，既可以交给业务逻辑层，也可以交给表现层来做。我个人更倾向在业务逻辑层来做，因为后台代码便于维护，根据文章权限设置按钮是否可见。
更具体点，一般的步骤如下：
- 用户输入文章检索/过滤条件（也可以不输入，提供默认文章列表），表现层验证用户输入是否有效，如果无效，给出提示；否则，提交给业务逻辑层；
- 业务逻辑层根据用户输入（也可以没输入，提供默认检索/过滤），创建 SQL 语句；
- 将生成的 SQL 语句，提交给数据访问层；
- 数据访问层建立数据库连接，并执行SQL，把文章列表返回给业务逻辑层（可以分页获取）。此时关闭与数据库的连接，并释放资源；
- 业务逻辑层把数据库访问层返回的文章列表，提交给表现层。同时负责“编辑”和“删除”按钮可见性；
- 表现层根据业务逻辑层返回的文章列表，按照式样呈现给用户。
关系型数据库中的数据都是以数据行进行存取的，而程序运行却是按对象处理，目前，大部分数据库驱动技术，如 ADO.NET、JDBC、ODBC 等，均是以行集的结果集一条条进行处理的。因此，为解决这个问题，就出现 ORM （Object / Relational Mapper）技术——对象与关系数据之间的映射技术。
比如，要完成一个用户购物打折的程序，用 ORM 思想如下：
public Double calcAmount(String customerid, double amount)
{
// 根据客户ID获得客户记录
Customer customer = CustomerManager.getCustomer(custmerid);
// 根据客户等级获得打折规则
Promotion promotion = PromotionManager.getPromotion(customer.getLevel());
// 累积客户总消费额，并保存累计结果
customer.setSumAmount(customer.getSumAmount().add(amount);
CustomerManager.save(customer);
// 返回打折后的金额
return amount.multiply(protomtion.getRatio());
}
这样的代码就非常清晰了，与数据存取逻辑完全分离，另外，业务逻辑也完全不需要考虑数据库的操作的操作，将它交给 CustomerManager 和 PromotionManager 两个类去完成。这就是一个简单的 ORM 设计。
持久层框架
目前，.Net 持久层框架列表：
.NET Persistence
BBADataObjects
DataObjects.NET
Data Tier Modeler for .NET
DotNorm
Eldorado.NET
Enterprise Core Objects (ECO™)
Entity Broker
eXpress Persistent Objects for .NET
FastObjects.NET
JC Persistent Framework
LLBLGen Pro
ModelWorks
NHibernate
Nolics.NET
Norm
Norpheme
ObjectBroker
ObjectSpaces
ObjectSpark
Objectz.NET
OJB.NET
OPF.Net (Object Persistent Framework)
ORM.NET
Pragmatier Data Tier Builder
RapTier
Sisyphus Persistence Framework
TierDeveloper
Bob.NET
ObjectPersistor.NET
Genome
Ibatis
easyobjects
这些框架成熟的不多，各自的设计理念也不太一样。其中，开源界比较流行的是 NHibernate 和 iBatis.Net。
参考
Microsoft MVC http://msdn.microsoft.com/en-us/library/dd381412(VS.98).aspx
ASP.NET MVC http://www.asp.net/mvc
（待完善）