.NET应用架构设计—工作单元模式（摆脱过程式代码的重要思想，代替DDD实现轻量级业务）

阅读目录：

• 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; }
    }
}

Order活动记录对象的字段部分。

namespace OrderManager.Business
{
    public partial class Order
    {
        public bool CheckOrder()
        {
            //执行部分业务验证工作
            if (this.OId <= 0) return false; 

            return true;
        }
    }
}

Order活动记录对象主体，纯粹为了演示而用，包含了一个简单的判断业务逻辑。

namespace OrderManager.Business
{
    public partial class OrderProducts
    {
        public long OrderId { get; set; } 

        public long PId { get; set; } 

        public float Price { get; set; }
    }
}

订单商品部分字段。

namespace OrderManager.Business
{
    public partial class OrderProducts
    {
        public bool CheckProducts()
        {
            //执行部分业务验证工作
            if (this.OrderId <= 0) return false; 

            return true;
        }
    }
}

每一个商品都包含了自己的逻辑验证。

我们接着看一下应用层入口方法是如何协调两个活动记录对象之间的业务操作和数据存储的。

namespace OrderManager
{
    using OrderManager.Business;
    using OrderManager.DataSource; 

    public class OrderManagerController : ControllerBase
    {
        public bool AddOrder(Order order)
        {
            using (UnitOfWork unitOfWork = new UnitOfWork())
            {
                order.CheckOrder();//执行业务检查 

                order.Products.ForEach(item =>
                {
                    item.CheckProducts();//执行每个活动记录对象的业务检查，这里也可以使用表模块来处理。
                }); 

                OrderGateway orderGateway = new OrderGateway(unitOfWork);
                var orderDbResult = orderGateway.AddOrder(order);//第一个数据库表操作 

                OrderProductsGateway productGateway = new OrderProductsGateway(unitOfWork);
                var productDbResult = productGateway.AddOrderProducts(order.Products);//第二个数据库表操作 

                if (orderDbResult && productDbResult)
                {
                    if (unitOfWork.Commit())
                    {
                        this.SendOrderIntegrationMssage(order);//发送成功集成订单消息 

                        return true;
                    } 

                    this.PushOrderProcessQueue(order);//将本次订单发送到处理队列中
                    return false;
                } 

                this.LogBusinessException(order);//记录一个业务处理异常LOG，以备排查问题。
                return false;
            }
        }
    }
}

为了简单演示示例，我直接使用实例化的方式来构造数据访问对象，实际使用时可以使用IOC工具来动态注入。

我们接着看一下数据层代码，数据层我使用表入口模式。

namespace OrderManager.DataSource
{
    public abstract class GatewayBase
    {
        protected UnitOfWork UnitOfWork { get; private set; } 

        public GatewayBase(UnitOfWork unit)
        {
            this.UnitOfWork = unit;
        } 

        public bool Commit()
        {
            return this.UnitOfWork.Commit();
        } 

        public void Rollback()
        {
            this.UnitOfWork.Rollback();
        }
    }
}

这是一个表入口基类。

namespace OrderManager.DataSource
{
    using OrderManager.Business; 

    public class OrderGateway : GatewayBase
    {
        public OrderGateway(UnitOfWork unit) : base(unit) { } 

        public bool AddOrder(Order order)
        {
            //这里可以使用你所熟悉的拼接SQL的方式直接操作数据库，而不需要ORM。
            return true;
        }
    }
}

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

    public class OrderProductsGateway : GatewayBase
    {
        public OrderProductsGateway(UnitOfWork unit) : base(unit) { } 

        public bool AddOrderProducts(List<OrderProducts> products)
        {
            //这里可以使用你所熟悉的拼接SQL的方式直接操作数据库，而不需要ORM。
            return true;
        }
    }
}

这是两个表入口对象，其实这部分代码是大家都比较熟悉的，所以我这里省略了，你可以直接拼接SQL语句来插入数据库。

namespace OrderManager.DataSource
{
    using System; 

    public class UnitOfWork : IDisposable
    {
        public void Dispose()
        {
            throw new NotImplementedException();
        } 

        public bool Commit()
        {
            return true;
        } 

        public void Rollback()
        {
            //
        }
    }
}

 

UnitOfWrok对象其实就是对数据库对象的System.Data.Common.DbConnection对象的封装，这里你可以使用你熟悉的方式来构造这个数据库连接对象和开启事务。

其实值得我们去欣赏的是应用控制器中的代码，在这里很协调的处理各个逻辑，最后记录下一些必要的日志和发送一些集成消息。你是不是发现你完全可以不使用DDD也可以处理部分业务系统了。

4.总结

活动记录模式+表入口模式+工作单元模式，其实我觉得可以很好的处理中小型业务逻辑，随着现在SOA化架构，很少再有多大的项目在一个解决方案里面。

最后还是那句话，提供一个参考资料，如果有兴趣可以进一步交流具体的设计，由于时间关系文章就到这里了，谢谢大家。

 

作者：王清培

出处：http://www.cnblogs.com/wangiqngpei557/

本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面