阅读目录：

• 1.背景介绍

• 2.过程式代码的真正困境

• 3.工作单元模式的简单示例

• 4.总结

1.背景介绍

一直都在谈论面向对象开发，但是开发企业应用系统时，使用面向对象开发最大的问题就是在于，多个对象之间的互操作需要涉及数据库操作。两个业务逻辑对象彼此之间需要互相调用，如果之间的互相操作是在一个业务事务范围内的，很容易完成，但是如果本次业务逻辑操作涉及到多个业务对象一起协作完成时问题就来了。

在以往，我们使用过程式的代码（事务脚本模式），将所有与本次业务事务范围内相关的所有逻辑都写在一个大的代码中，就算你适当的提取重复代码，效果也不大，因为你永远都摆脱不了夸多个对象互相操作的困境。如何确认你是否在这个困境中，你只要看你的所有事务操作的入口都只有一个业务方法。比如当你添加一个订单的时候，你同时将订单跟随的商品都一起在“添加订单”的方法中处理的，而不是在另外一个“添加订单商品”的方法中，这两个方法位于不同的表模块类中。

本章将介绍一个模式，此模式专门用来在开发企业应用系统时，协调多个业务对象在一个业务事务范围内，保证一个完整的事务。

2.过程式代码的困境

其实开发应用系统与开发某个框架或者组件之间的最大区别就是需要考虑数据的持久化，而持久化的逻辑也是和业务逻辑息息相关的，某个方法的最后动作就有可能是添加一行数据或者更新一个字段。而非应用系统的代码往往在最后的时候才去统一刷新最终的持久化文件，而且此类程序很少存在事务性数据操作。就算有，使用内存事务处理也是比较简单的，不需要考虑那么多的服务端的事情。

我之前也写过很多组件、框架，虽然谈不上什么复杂的东西，但是给我的经验和感悟就是，如何将其细致的设计粒度用在企业应用系统中，如何进行复杂而细致的OO设计开发。其实，如果我们不能够打破过程式代码的格局，那么看再多的OO知识也是心有余而力不足，反而会让你产生很多负面的情绪（因为我有过这个经历）。

其实我们还是缺少正确的方法而已，本文中UnitOfWork模式将帮助我们走出过程式的业务逻辑，走向起码的面向对象开发。有了UnitOfWork你可以随意使用Table module 、Activa Record、Domin Driven 模式，而且你可以根据自己的项目需要将其在大的布局上进行SOA划分（CQRS），让各个模式在各自适合的场景中发挥极致。

3.工作单元模式的简单示例

这里我们依然使用简单的订单购物业务作为示例来讲，毕竟大家都懂得这部分的的业务概念。本实例业务层使用Active Record模式。

namespace OrderManager.Business
{
    using System.Collections.Generic;

    public partial class Order
    {
        public long OId { get; set; }

        public List<OrderProducts> Products { get; set; }
    }
}