极限编程,持续集成,测试驱动开发,重构。
1.从领域层开始
三种模式最简单的是事务脚本模式。比较符合大多数人的习惯。它将每种系统事务的逻辑很好的封装在功能完善的脚本中,而且比较适合于在关系数据库之上构建。
它的主要问题是对复杂业务逻辑的支持不够,尤其是不善于处理重复代码。
最复杂的是领域模型模式。缺点是难以学会使用领域模型。第二个缺点就是它与数据库的连接。
表模块模式是这2个极端之间一个比较好的折中。在处理领域逻辑上,它比事务脚本强。虽然它在处理复杂领域逻辑上不如领域模型,但是对于关系数据库和其他一些东西
而言,它还是游刃有余的。
2.深入到数据源层
一旦选择了领域层,你就必须决定如何与数据源相联系。这是的选择是以领域层选择为基础的,所以由该选择驱动。
1.事务脚本的数据源
最简单的事务脚本包含其自身的数据库逻辑,避免这样做。分离数据库,使得领域逻辑和数据源逻辑这两部分界限划分变得有意义,即使是最简单的应用,也要分离。
此时,可选择的数据库模式包括行数据入口和表数据入口。
两者选哪个,很大程度上取决于实现平台的方便以及系统未来的发展方向。在行数据入口中,每个记录都通过显式的接口读入到一个对象中。在表数据入口,程序员
可以少些一些代码,因为他不需要写那么多存取器代码就可以读取数据,但是编程接口却是相对隐式的,这些接口依靠对记录集的访问(类似于映射)。
最关键的决策在于所用开发平台的其余方面。如果所用的平台包含很多支持记录集的工具,特别是UI工具和事务性的断接记录集,则选择的天平就偏向表数据入口。
在这种情况下,通常无需其他的OR映射模式。结构映射问题在很大程度上得到缓解,因为内存数据结构与数据库结构间的映射高度一致。也可以考虑工作单元,但
一般来说,在脚本中跟踪变化的部分很容易。在这里,无需关心大多数并发问题,因为脚本基本上对应一个系统事务。因此,可以将整个脚本封装在单个事务中。异常
一般发生在一个请求将数据读取出来编辑,而下一个请求视图对变化进行保存的情况下。在这种情况下,一般使用乐观离线锁。
2.表模块的数据源
选择表模块最主要的原因是有一个好的记录集框架。此时,就需要一个与记录集配合良好的数据库映射模式,就是表数据入口。使用了这个模式后,在数据源层几乎不需要
再加其他什么功能。在比较理想的情况下,记录集中都内置了某种形式的并发控制机制,这就使得它成为工作单元,从而进一步降低了开销。
3.领域层的数据源
领域模型的最大缺点是它与数据库的连接很复杂。而这个复杂程度实际上取决于模式的复杂程度。
如果领域模型相当简单,例如只有十几个与数据库相关的类,则活动记录就可以了。如果希望耦合更加松一点,则可以使用表数据入口或行数据入口。随着复杂度的进一步
增加,可以考虑使用数据映射器,这种方法确保领域模型尽可能与其他各层互相独立。但是数据映射器也是实现起来最复杂的一种模式。
3.表现层
表现层在很多方面都独立于其下层的选择。你首先会问,是提供胖客户用户界面,还是html浏览器界面?胖客户界面的效果更好,但是你必须为此付出更多的代价,即对客户端程序
进行控制和部署管理。如果情况允许,尽可能使用html浏览器方式。实在不行,再用胖客户用户界面。
如果你走html路线,就必须决定如何组织你的应用。建议是使用模式---视图---控制器 作为设计基础。如果确定使用该模式,则剩下来的就只有两个决定:一个是控制器,一个是
视图。
关于视图的两个选择:模板视图和转换视图。这主要取决于开发组编程时使用的是服务器页面还是XSLT。尽管我非常欣赏转换视图额外提供的测试能力,但模板视图还是略占上风。
如果你开发的是一个由多种表现形式的站点,请使用考虑两步视图。
如何与下层通信取决于两个因素:一个是待通信的是哪一层,另一个是它们是否处于同一个运行的进程。如果可能,建议将所有的东西都运行在一个进程中。这样就不用担心低效的
进程间通信。如果实在无法再一个进程中完成,可以将领域逻辑层用远程外观包装,然后使用数据传输对象实现与web服务器的通信。
5.其他分层方式
Brown : Fowler
1.表现层 表现层
2.控制层/中介层 表现层
3.领域层 领域层
4.数据映射层 数据源层
5.数据源层 数据源层
应用控制器(模式)是表现层与领域层之间的中介层,而数据映射器则是数据源层与领域层之间的中介层。
Core J2EE : Fowler
1.客户层 运行于客户端的表现层(如,胖客户系统)
2.表现层 运行于服务端的表现层(如,http处理程序,服务器页面)
3.业务层 领域层
4.集成层 数据源层
5.资源层 需要与数据源层通信的外部资源
业务层和集成层存在简单的对应关系,资源层包含了集成层需要连接到的外部服务。主要的区别在于它将表现层分成了客户端部分(客户层)和服务端部分(表现层)。这是非常有用的
隔离方法,但同样,这种分层方式不是任何时候都需要。
Microsoft DNA 分层模型 : Fowler
1.表现层 表现层
2.业务层 领域层
3.数据访问层 数据源层
DNA 中的记录集实际上充当一种各层之间的数据传输对象。业务层能够根据自己的方式修改记录集,甚至可以自己创建一个新的记录集(少数情况)。虽然这种形式的通信方式有点笨拙,
但它的好处在于允许表现层使用一些数据敏感的GUI控件,这些控件甚至可以以创作由业务层修改了的数据。
这种情况下,领域层通常组织成表模块形式,而数据源层使用表数据入口。
Marinescu 分层模型 : Fowler
1.表现层 表现层
2.应用层 表现层(应用控制器)
3.服务层 领域层(服务层)
4.领域层 领域层(领域模型)
5.持久层 数据源层
将服务层从领域层剥离出来的一个原因,源于将工作流逻辑从纯粹领域逻辑中的剥离。服务层所包含的逻辑一般都特定于某个用例,并与其他一些基础设施互相通信,如消息机制。
Nilsson 分层模型 : Fowler
1.顾客层 表现层
2.顾客帮助层 表现层(应用控制器)
3.应用层 领域层(服务层)
4.领域层 领域层(领域模型)
5.持久访问层 数据源层
6.公共存储过程层 数据源层(可能包含一些领域层)
7.私有存储过程层 数据源层(可能包含一些领域层)
Nilsson 中使用了一种较复杂的分层模型。映射到这种模型有点复杂,这是因为Nilsson太广泛的使用存储过程,并且为了性能远远而鼓励在存储过程中使用领域逻辑。
https://juejin.im/post/5c51b80be51d45677567af13