8.企业应用架构模式 --- 通盘考虑

	极限编程,持续集成,测试驱动开发,重构。

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

 

 

 

 

 

 

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值