2008-1-27
第一部分 表述1 分层
1.1 三个基本层次
三层架构:表现层:表现逻辑处理用户与软件间的交互。主要职责是:
ü 向用户显示信息
ü 把从用户那里获得的信息解释成领域层或数据源层上的各种动作。
数据源层:数据源逻辑主要关注与其他系统的交互,这些系统将代表应邀完成相关的任务。主要的数据源逻辑就是数据库,它的主要职责是存储持久数据。
领域层:领域逻辑(业务逻辑),它就是应用必须做的所有领域相关的工作:
ü 根据输入数据或已有数据进行计算
ü 对从表现层输入的数据进行验证
ü 根据从表现层接收的命令来确定应该调度哪些数据源逻辑。
三层的关系:领域层是核心!表现层是系统对外提供服务的外部接口;数据源层是系统使用外部服务的接口。
分层结构依赖原则:领域层和数据源层绝对不要依赖于表现层。也就是说,在领域层和数据源层的代码中,不要出现调用表现层代码的情况。
区分逻辑层次的是否划分正确的简单测试原则:层次替换修改原则(注:我自己给起的名字)——假想向系统中增加一个完全不同的新层,例如为Web应用增加一个命令行界面层。如果这个过程中,发现需要重复实现某些功能,则说明可能有一些本应该在领域层实现的逻辑,现在在表现层实现了。类似的,你可以假想一下,将后台数据库更换成XML文件格式,看看情况又如何?
2 组织领域逻辑
事务脚本模式与领域模型模式。
范例:
核心问题是:对于同一给定的合同,不同种类的产品有不同的收入确认算法。计算收入确认的方法中必须先确定给定合同中产品的种类,然后应用正确的算法,之后再创建相应的收入确认对象[U1] (RevenueRecognition)来保存计算结果。
使用事务脚本计算收入确认
a Recognition Service:确认服务
calculateRecognitions(contractID):根据合同(contract)ID计算确认
findContract(contractID):向数据入口发送“查找合同”消息,根据合同ID查找合同,返回合同结果集
insert revenue recognitions:插入收入确认。
使用领域模型计算收入确认
利用了典型的策略模式(GoF),将对于不同产品的确认策略分离出来,以实现对于不同产品采取不同的计算确认策略。
class Contract{
private Product product;
public void setProduct(Product product){
this. product= product;
}
public Product getProduct(){
return this. product;
}
public void calculateRecogntions(){
getProduct().calculateRecogntions(this);
}
}
class Product{
private RecogntionStrategy recogntionStrategy;
public void set RecogntionStrategy (RecogntionStrategy recogntionStrategy){
this. recogntionStrategy = recogntionStrategy;
}
public RecogntionStrategy getRecogntionStrategy (){
return this. recogntionStrategy;
}
public void calculateRecogntions(Contract contract){
getRecogntionStrategy ().calculateRecogntions (contract);
}
}
2.1 服务层
概念:处理领域逻辑的常见方法是将领域层再细分成两层。服务层独立出来,置于底层的领域模型或表模块之上。
职责:表现逻辑与领域层的交互完全通过服务层,就好像应用程序的API一样。服务层是放置事务控制和安全等功能的好场所。
组成:最小化情况下,服务层只是一个外观,所有实际的行为都在下层的对象中,服务层所做的只是将上层调用传递到更低层。此时,服务层提供一个更易于使用的API,因为它的方法通常根据用例来组织。该方式是Fowler最为推崇的方式。另外还有将服务层实现为一个事务脚本或使用控制器-实体模式。
3 映射到关系数据库
3.1 架构模式
讲了几种入口(Gateway)模式后,Fowler指出:一种更好的方法是把领域模型和数据库完全独立,可以让间接层完成领域对象和数据库表之间的映射。这个数据映射器处理数据库和领域模型之间所有的存取操作,并且允许双方都能独立变化。
零雨其蒙注解:目前采用Hiberante之类的O/RM框架就是实现该模式。
另外,Fowler不推荐把入口(Gateway)用作领域模型的首选持久化机制。
即使使用数据映射器作为首选持久化机制,还是可以使用数据入口来封装被视为外部接口的表或者服务。
零雨其蒙注解:目前采用DAO模式是更好的表述。
[U1]相当于《结算方式确认通知书》???