业务逻辑模式——事务脚本模式

事务脚本模式是简单的业务逻辑实现方式,它将每个用户操作映射为一个方法并在同一个物理事务内执行。适用于不涉及复杂领域建模的场景,如简单的CRUD系统。在实践中,可以通过命令模式实现,允许灵活的数据交换。虽然简单,但在适当情况下使用事务脚本模式是完全合理的。

事务脚本模式(Transaction Script, TS)

事务脚本模式可能是最简单的业务逻辑模式,它完全是过程式的。

模式概论

事务脚本是一个方法——用户通过表现层的操作发送的请求进而形成的方法。
事务——通常指执行的业务
脚本——指一组系统执行的操作(也就是脚本)与每个用户操作在逻辑上关联起来。

TS建议跳过任何面向对象设计,把业务组件直接映射到所需的用户操作上。
在TS里,每个所需的用户操作的实现都是在物理事务的边界里从开始执行到结束。数据访问通常封装到一组组件里,组件通常会放入数据访问层。按照模式,TS没有包含任何面向对象设计的成分。通过TS建模的任何逻辑都是通过IF、WHILE和FOR等语言语法元素表达。

注意:通过TS实现业务逻辑的系统有一个比较紧凑的分层架构,在这个架构里,TS与应用程序层重合,直接连接数据访问层。最终的架构与经典的三层架构一样。

下图(事务脚本模式的鸟瞰图)概述了事务脚本模式的精髓
在这里插入图片描述
TS己经用了很多年,但不会那么快被淘汰只有一个原因:它推动从任务的角度看待业务逻辑,正如你在过去的章节里看到的,这正是提高用户体验的关键。

何时选择事务脚本

TS适合业务逻辑简单,最好是不大可能改变和发展的简单场景。
通常,TS适合任何不打算使用领域建模的场景,不管何种原因,不管是复杂性有限还是技能有限。

重要:从数据库快速推断的脚本对象模型,虽然仍可能被称为领域模型,但它其实是贫血领域模型。

如在简单的CRUD系统中,且缺乏领域建模相应的知识时候,可以使用TS。其中,通过把系统分成命令和查询两部分,使用TS实现命令部分非常容易,可以把更多时间和精力用于为系统的查询部分设计一个有效的模型。

注意:简单和复杂都是不容易衡量的概念。更重要的是,什么是简单以及什么是复杂取决于个人的态度和技能。如果你做了很多年面向对象设计,也对你的东西很了解,那么设计一个简单的领域模型比起切换回去过程式编码对于你来说可能更简单、更快速。因此,没有必要每次觉得复杂性低于一个普遍认同的临界值时就选择TS。
更简单地说,一旦你觉得你这个系统有了全面的认识,并且这个系统就需求和业务规则而言并没有太过复杂,你就应该认真考虑一下TS。对象使得代码优雅,但只有在代码可以工作并且正确工作的时候这种优雅才有意义。使用TS并没有什么好羞耻的,尤其在适合使用TS的情况下。

模式实践

就实现而言,可以在一个类里为每个事务脚本创建一个单独方法,它可能是静态的,也可以为每个事务脚本创建它自己的类。这样做的话,最终会得到命令(Command)模式的一个很好的实现。

衔接命令模式
命令模式是其中一个最常用的行为设计模式,它使用对象来表示操作。命令对象封装了一个操作及其所有参数。通常,命令对象暴露一个标准接口,以便调用方可以在不深入了解实际执行任务的命令类的情况下调用任何命令。下面是一个简单的例子:

public interface IApplicationCommand
{
    int Run();
}

public class BookHotelRoom : IApplicationCommand
{
    Customer _guest;
    DateTime _checkIn, _checkOut;
    String _confirmationNumber;
    //其他内部成员
    
    public BookHotelRoom(Customer guest, DateTime checkIn, DateTime checkOut)
    {
        _guest = guest;
        _checkIn = checkIn;
        _checkOut = checkOut;
    }

    public string ConfirmationNumber
    {
        get
        {
            return _confirmationNumber;
        }
    }

    public int Run()
    {
        // 启动事务
        // 检查有没有适合入住的房间
        // 检查客户信息(是否己经是客人,及其支付方式、个人偏好)
        // 计算房间入住率
        // 在预定数据库表里添加一条新记录
		// 生成确认号
		// 提交事务
		// 向这个客户发送电子邮件
		// 把确认号保存到本地成员confirmationNumber
    }
}

TS模式并未强制使用任何类型或格式进行数据交换。向脚本提供数据以及从脚本获取数据都取决于你。因此可以随意选择适合你的偏好和设计需要的方案。常见的做法是使用简单的数据传输对象(DTO)。

评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

木白说

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值