阅读目录：

• 1.背景介绍

• 2.简单介绍表模块模式、事务脚本模式

• 3.正确的编写表模块模式、事务脚本模式的代码

• 4.总结

1.背景介绍

要想正确的设计系统架构就必须能正确的搞懂每个架构模式的用意，而不是胡子眉毛一把抓。现在有一个现象是什么呢，项目的结构从表面上看是很不错，层分的很合理，其实对业务系统来说也就那么几种层设计方法，但是现在很多项目的逻辑架构的设计不是理想，有很多概念大家并不是很了解，当然也许每个人对技术的追求不同罢了。不管你追求不追求，事实我们还是要去往正确的方向努力才对的。

很多人包括我自己在内，都是写过很多年的过程式的代码，层对我当年来说就是个摆设而已，最典型的问题就是我们总是将表模块模式和事物脚本模式一起混着使用，什么意思呢，就是说我们都会使用一些代码生成器来根据数据库中的表来生成三层架构中的业务层和数据层，有些比较好的代码生成器也可以帮你把UI层中的部分视图也生成好，确实很强大，有些场合下这是一中最合适的过程。

但是现在的系统已经不在是那样的了，其中重要的一点就是业务复杂了，如果我们还稀里糊涂的编写着代码，最后只会成为你或者团队的技术债务。

2.简单介绍表模块模式、事务脚本模式

我们简单了解一下这里所谓的“表模块模式、”事务脚本模式“到底是什么样子的模式，最关键是你也许就知道了你目前所使用的业务层架构风格是什么模式，强调一下“表模块模式”、“事物脚本模式”都是业务层的构架模式。

表模块模式：

简单讲就是你数据库中的每个表对应着业务层中的一个对象定义，如果你有一个Product表，那么你在Business Layer中就有一个Product.cs文件，当然这不是绝对的，你也可以将库中的视图也定义一个类型，如，OrderProduct.cs，也是可以的。然后每个类中的所处理的逻辑都是跟这张表相关的，你在Product.cs中的代码就不要包含Order.cs中的代码了。目前来看是有的，因为现在大部分的项目都是在写着使用过程式的代码，也就是事物脚本模式，这样难免会将其他类型中的代码写到本类中。

事物脚本模式：

事务脚本模式就是过程式的代码，只不过它的指标就是每一个代码段独立完成一个业务单元，而不是到处都是过程代码，事物脚本模式还是很强调逻辑的统一性的。

使用此模式进行写代码时，你就不要单纯的使用数据库中的表名来定义业务类了，因为你是使用事务脚本模式的，你需要站在业务角度来规划你的业务层中大概包含哪些业务概念，然后使用这个业务概念来命名你的类。比如：UserOrder，UserOrder，类似这样的定义，当然这里只是个假设而已，你不要站在数据库的脚本来设计业务层就行了，这样你就起码不会使用到很细粒度的类型，哪怕下一次迭代进行重构也是可以的。