关于企业应用架构模式总体分析

分析领域逻辑的方法，主要可选的几种模式分别是：事务脚本、表模式、领域模型。

选择的依据主要是视领域逻辑的复杂性而定。

在上述的3种模式中，最简单的事务脚本模式。它比较符合大家习惯的过程模型。所以它采用的依旧是“面向过程”的思想。它将每种系统事务的逻辑很好的封装在功能完善的脚本（方法）中，比较适合于在关系数据库上构建。它的主要问题是对复杂业务逻辑的支持不够！

最为复杂的是领域模型模式，当领域逻辑非常复杂时，建议使用。当然它的缺点就是它与数据库的连接。

表模块模式是介于前面这个模式之间的一个模式，在处理领域逻辑尚，它比事务脚本强，但是在处理复杂领域逻辑上却又不如领域模型。

关于领域逻辑对应的数据源：

关于数据源层的选择，通常是以“领域层”的选择作为基础。

事务脚本的数据源：

关于事务脚本的数据源，在选择时，可供选择的数据库模式有：行数据入口和表数据入口。当然具体选择哪一种，看如何方便如何来吧。行数据入口中，数据库表中每个记录都通过显式的接口读入到一个对象中。在表数据入口中，采用隐式接口依靠对记录集的访问（类似于映射）来实现。事务脚本将整个脚本封装在单个事务中，异常一般发生在一个请求将数据读取出来编辑，而下一个请求试图对变化进行保存的情况下。所以，在这种情况下，一般使用乐观离线锁，避免由于挂起会话所导致的大面积加锁的情况。

表模块的数据源：

使用表模块最好有一个好的记录集框架，因此，需要一个与记录集配合良好的数据库映射模式，当然就是表数据入口。

领域模型的数据源：

领域模型的最大的缺点是它与数据库的连接很复杂，但是复杂程度实际上取决于模式的复杂程度。

简单点的，就直接采用活动记录，如果希望耦合度松散些，那么就采用表数据入口或行数据入口。

复杂点的，就需要考虑使用数据映射器，尽量将领域模型与数据源模型分离开，尽可能使领域模型与其他各层相互独立。

表现层：

  个人观点，表现层就采用比较熟悉的MVC作为设计基础，采用这种模式，主要就是确定控制器与试图技术而已。