语源科技BlogJava-我爱oo,我爱java

DAO-持久层-领域对象-贫血模型

兼听则明 — Mon, 10 Apr 2006 14:21:00 GMT

原文

关于"贫血模型"的讨论几乎没有停止过,在openfans.org的开发过程中,我们也讨论了很久,我觉的有很多东西应该记下来:
明确一下意思先:
DAO:数据操作对象,会操作数据库
持久层:能提供对象持久化服务的一系列组件或服务
领域对象:描述领域模型的对象,是通过业务分析进行系统建模的产物
贫血模型:就是domain object只有属性的getter/setter方法的纯数据类，所有的业务逻辑完全由一个所谓的Manager来完成(又称 TransactionScript)，这种模型下的domain object被Martin Fowler称之为“贫血的domain object”
常见的类基本结构如下:
一个业务数据类叫做Item，
一个DAO接口类叫做ItemDao
一个DAO接口实现类叫做ItemDaoHibernateImpl
一个业务逻辑类叫做ItemManager(或者叫做ItemService).

观察上面的几个类很容易发现问题:
1:Item和ItemManager实际是操作与数据的关系,实际完成的就是经典OO中的一个对象的能力;
2:当有许多Item时类组变得很庞大,产生很多 xxxDao xxxImpl xxxManager 其中包含大量重复代码;
按<<重构>>的观点,上述代码存在以下臭味:
1:重复的代码   xxxDao xxxImpl xxxManager(通常)
2:霰弹式修改，一个变化影响多个类,类之间不够高内聚 item变化-->Dao,Impl,Manager均要变动
3:依恋情结,两个类之间互相作用过多 item<->Manager
4:平行继承体系,当增加一个新类时总是要增加另一个类
5:夸夸其谈未来性,在没有任何暗示的情况下考虑扩展 Dao,实际HibernateImpl可能n年内是唯一的Dao实现
6:纯稚的数据类，只有数据的类 item

我觉的贫血模型是系统分析设计方向性错误的产物:
1:没有进行领域建模---以数据表结构为中心,而不是业务模型为中心的思考方式,使设计人员选择Item为考虑问题的出发点
2:将DAO与持久层混淆---我们需要的一种持久化服务,DAO紧紧是提供数据操作能力而已,Hibernate是一种高级的服务(他已经包含了DAO,而不是相反),已经完成了所有的持久层服务.
3:过于强调低偶合---将一些本来一些提供单一职责的内容分散在多个单元中使客户端依赖更多的接口,而忘记了高内聚原则.
4:Spring的能力限制---由于Spring现阶段不支持对于领域模型的服务注入,使设计人员将操作和数据分开,并将领域变为DataOnly的.
(Spring2.0将在很大程度上解决这个问题)

我认为良好的解决方案:
首先领域建模,建立领域模型-->合并前面所说的Item和ItemManager成为 domainItem;对于数据库服务,
1:如果考虑领域层包含数据操作能力,则建立DAO并选择其它好的DAO方案比如IBATIS或Hibernate之类的组件;
2:如果考虑将数据库(或其他存储界质)存储考虑在领域之外成为持久层,
    a:则或者对持久层框架同时建模,同时选择合适的组件为持久层服务提供存储服务(包括DAO--亦可选择IBATIS/Hibernate组件),
    b:或者直接使用Hibernate/JDO等框架实现持久化服务,领域层直接使用持久层服务,对领域对象进行持久化和反持久化(从持久层获取以持久化的对象).

其他:
实际上,作为一种解决方案,所谓"贫血模型"的具体使用,并不会有太大的问题,尤其是使用一些代码生成工具或已经做好相应的基本框架时,很多软件的核心价值都在于对客户提供的服务,而其内部则成为黑盒,我们只要合理的解决业务问题,就是"王道"了,对于代码的臭味,可以慢慢重构--这也需要成本呀.

再其他:
有人说,我们的业务就是CRUD,领域模型只有数据类就足够了.我觉的这是搞错了方向------只有CRUD时,只有处理CRUD的那些类才有必要进行建模(他们才是领域模型),而所谓的User\Item等数据类则完全没有必要进行建模,更不要谈领域了.

贫血之外:
实际上,软件\OO方法的外延大的很,更多问题与数据库存储无关(但也有贫血问题),所以建模才是根本,OO方法的原则才是我们必须掌握的.

兼听则明 2006-04-10 22:21 发表评论

SQLServer的一个bug

兼听则明 — Sun, 05 Feb 2006 14:37:00 GMT

SQLServer一个bug终于被我碰上了

我有一个表使用字符类型存储数字值,想进行汇总计算：

sum(case when isnumeric(FieldName)=0 then 0 else cast (FieldName as numeric) end)
简单试了一下没有问题，可是今天数据中有一个 ’2.1234567E7‘ isnumeric返回1 cast 返回错误

呜呜。。。。
怎么办......

兼听则明 2006-02-05 22:37 发表评论

使用Quartz要注意的一个问题

兼听则明 — Sun, 22 Jan 2006 16:52:00 GMT

当设置一个Schedule的startDate早于 new Date()，并且调度周期又触发于startDate和new Date()之间时，就会立即触发当前job。简单的解决方式是将startDate设为new Date().

兼听则明 2006-01-23 00:52 发表评论

使用abator自动生成ibatis代码的经验及碰到的问题的解决方案

兼听则明 — Sat, 21 Jan 2006 05:51:00 GMT

1:abator下载:http://ibatis.apache.org/abator.html
2:将abator安装到eclipse中
3:此时可以新建一种文件类型：Abator for iBATIS Configuration File,建立一个
4:在　jdbcConnection 中设置要mapping的数据库的jdbc连接
classPathEntry 是你的jdbc driver类路径
5:javaModelGenerator,sqlMapGenerator,daoGenerator 分别设置　java dataObject、sql mapping文件和 DAO 接口、实现类的生成位置:targetPackage 目标包，targetProject：eclipse项目
6:daoGenerator 中可以设置属性　　type: ibatis 或　spring 指定生成的dao实现类是使用com.ibatis.dao.client.template.SqlMapDaoTemplate
还是
org.springframework.orm.ibatis.support.SqlMapClientDaoSupport
7: table 中 tableName　指定要处理的表名
　　可以有多个table
8:table中可以包含子元素　generatedKey: 使Insert方法可以返回值－－由指定的column　mapping
9:generatedKey中的sqlStatement属性可以是获取sequence的SQL，也可以是获取自增值的SQL
比如:Oracle的 select theSequence.nextVal from dual
SQLServer的 SELECT @@IDENTITY as column_name
10:保存文件，选中文件，右键菜单选择Generate iBATIS Artifacts! ok...

使用abtor生成的iBatis代码出现xml解析错误的解决方案
如果按上述方式生成的代码有xml解析错误：请下载这个

注意，该文件名为Abator.rar.txt实际是一个rar文件，只是上传服务器有文件类型限制所以只好加了扩展名txt。
请去掉.txt后解压。

使用
org.apache.ibatis.abator.core_0.5.1.jar
替换调你的 eclipse\plugins 的同名文件即可。

然后重新生成代码。 OK 应该可以咯....

我改了一点代码，需要可以留言。

兼听则明 2006-01-21 13:51 发表评论

在eclipse－plugin开发中碰到的怪问题：(eclipse 3.1.1 + wtp1.0)

兼听则明 — Fri, 20 Jan 2006 10:45:00 GMT

一个popupMenus Extensions，
objectContribution：objectClass*: org.eclipse.core.resources.IFile

在action的Class代码中：
public void selectionChanged(IAction action, ISelection selection) {
   StructuredSelection ss = (StructuredSelection) selection;
        this.selectedFile==(IFile)ss.getFirstElement(); //此处抛出异常
}

上述代码的异常非常奇怪：
根据的的跟踪，ss.getFirstElement()返回值是File，该类实现了IFile接口，
而且我用 ss.getFirstElement().getClass().isAssignableFrom(IFile.class)返回是false；
真是奇怪！－－－有人知道为什么吗？

另外在实践eclipse plugin开发过程中也有几个心得：(肯定能用，但未必最佳)

1、如果开发plugin，所有的依赖库都要包含到 Plug-in Dependencies 中；而不能只是引入到工程中。
2、如何输出到console：
MessageConsole mc=new MessageConsole("****",null);
IConsole[] cs=new IConsole[1];
cs[0]=mc;
ConsolePlugin.getDefault().getConsoleManager().addConsoles(cs);
mc.activate();
PrintStream out=new PrintStream( mc.newOutputStream());
out.println("*******.");
3、如何获取依赖工程的输出路径：
selectedProject：当前工程－－－由用户选择
String[] ps= selectedProject.getRequiredProjectNames();
IWorkspace w= selectedProject.getProject().getWorkspace();
for(int i=0;iIResource r=w.getRoot().findMember(ps[i]);
try{
   IJavaProject jp=new JavaProject((IProject)r,null);
   File source=new File(jp.getProject().getLocation().append(jp.getOutputLocation().removeFirstSegments(1)).toOSString());
        //作你的事情.....
}catch(Exception e){
   //不是javaProject
   e.printStackTrace();
}
4、如何使用进度Dialog：
Shell shell = new Shell();
ProgressMonitorDialog dialog = new ProgressMonitorDialog(shell);
IRunnableWithProgress thread = new SomeRunner(shell);
dialog.run(true, false, thread);
//=============================
private class SomeRunner implements IRunnableWithProgress {
    public void run(IProgressMonitor monitor)throws InvocationTargetException, InterruptedException {
   monitor.beginTask("一些信息", 数值-总工作量);
        for(;;){
        // 一些工作
        monitor.worked(数值-已完成工作量); //实际中，我得情况不太相符，不明白，但差不多 :(
        monitor.setTaskName("一些信息");
    // 一些工作
       }
        monitor.done();
    }
}

兼听则明 2006-01-20 18:45 发表评论

Spring 中的异常悖论

兼听则明 — Thu, 19 Jan 2006 13:45:00 GMT

这个题目可能有些危言悚听,使用Spring的同行不用害怕，只是因为工作中碰到一些问题，才偶然想到这个问题。

首先要明确两个问题：
1、系统隔离原则：
即系统间依赖应该是清晰的，不因为一个系统的故障影响其他系统，甚至整个系统。
2、简单应用习惯：
普通程序员只会处理checked Exception,负责任的程序员会处理被调用的函数可能抛出的异常(根据源码或javadoc)

我们碰到一个情况：
使用Spring的 init 特性初试化一个bean--一个使用Qutarz的调度程序。初试化过程中会抛出RuntimeException，从而造成Spring容器的整个初试化失败。首先我们修改了程序，捕获了所有异常，随后在编码指南中加入了一句话："所有使用Spring-init机制初试化的类必须在init中捕获所有异常：Exception"。因为只有如此才能保证整个系统不会因为局部问题而完全瘫痪。

我觉得这是Spring对异常处理的一个悖论：
正方：底层异常都封装成Runtime的,经过几次包装--->简单应用习惯--->异常被抛出领域层(init场景下:由Spring处理)
反方: 一个类的失败可以造成整个系统的失败---->Spring被RuntimeException宕掉---->不符合系统隔离原则

当然充分的测试可能可以解决这个问题：但是要注意，测试只能证明系统有bug，不能证明系统没有bug。

解决方案：
1、好的设计习惯：将应该隔离的系统隔离开-->使用不同的Spring配置文件.
2、接口层错误处理：在接口层应该尽量对可以处理的异常进行处理,然后以合理的方式传递给上层.

PS:在与人交互的系统中都应该给最终用户合理的错误提示，所以表现层应该尽量捕获非业务的RuntimeException给最终用户更好的操作感受。

兼听则明 2006-01-19 21:45 发表评论

白马非马的面向对象分析

兼听则明 — Thu, 19 Jan 2006 06:16:00 GMT

公孙龙，六国时辩士也。疾名实之散乱，因资材之所长，为“守白”之论。假物取譬，以“守白”辩，谓白马为非马也。

以马作为进行问题域进行建模，已知存在白马这种类型。显然存在马的超类，并且马类包含一个属性－颜色，是否需要建立白马的子类呢？显而易见的是，当马的颜色属性是白色时，马的一些实例表达了一个白马的特殊实例群(由此我们可以得知：白马显然是马)，根据里氏替换原则，子类型必须能够替换掉它们的基类型，显然在分析了马的行为模式以后，我们可以得出结论：白马可以替换马。－－－－！难道真的要建立白马、黑马、X马的子类吗？
   我认为可以从以下几方面进行分析。

1、类的职责(很大程度上等同于服务能力，操作方式):
    设计一个类，首先要从类职责的分析入手，一个类要承担响应的职责，反过来说同样的职责应该由同样的类承担，否则会造成类泛滥，实例孤单的状况。如果领域内马和白马承担同样的职责，应该只建立马一个类，不应该只见树不见林，造成不抽象的类的产生。

2、类的行为模式(当类承担响应职责时，如何扩展)：
   分析一个类要从类的行为模式入手，既然一个类要承担责任，其承担的责任表现方式是否一样呢呢？这就是她的行为模式，这也是里氏替换原则主要起作用的地方，如果两个类的职责相当，但行为模式不同则不能成为超类和子类的关系(比如"著名"的正方形不是长方形问题)。马类，作为超类，基于一些特殊的行为方式：吃草，跑...，对于白马她的行为模式和马是一样的，并没有不同，所以白马是马而非马的同根继承子类。对于长方形和正方形都是具有相同计算面积算法(职责)的四方形的子类。

－－－－－－－以下是关于此事的一些扩展分析－－－－－－－－－－－
3、子类的产生：
    何时需要产生子类呢：是对其父类的职责进行扩展，白马没有对父类的职责进行扩展，所以不是马的子类。首先子类要扩展超类，其次子类不能重写或废除超类的职责。

4、属性，状态的区别(类的域)
   对于一些类，在状态不同时，会有不同的表现(状态机模式),所以，类的getter，setter的部分包含两种不同的特性，对于属于状态的部分，是我们要仔细分析的，而"白"马则属于属性类(非状态)的域, 一般来讲，一个类的实例要能提供相应的差异服务(由于状态不同)最好使用不变模式[生存周期状态不变]或状态机[生存周期有状态,但状态不由调用者控制]来实现。

5、抽象类和接口
   由于java的单根继承特性，很多设计人员不敢定义抽象类为继承树根，一定要先定义马的接口，在建立抽象马，作为一种"准规范"无可厚非，但我认为这是不愿承担责任的表现，有行为的基类应该可以(必须?)从类定义开始，避免白马类(一旦马成为接口，白马的产生就更加"名正言顺"了)的出现.将来如果发生变化可以通过重构(导出接口和使用委托)，解决问题。

6、对象的创建(组装)和使用应该分开
   既然对象的状态如此重要，属性有有很大程度的不变性(白马在构造时就用该是白的，并且一生不变)，而骑马的人不必要求马的属性(!),所以，我们应该将马的构造和使用分开，使领域模型更清晰。使用一些Ioc容器，比如Spring就能很好的解决这些问题。

7、分析问题的领域
   说了这么多，有一个问题；如果有一个马的研究机构，专门对不同颜色的马进行专题研究，马的颜色可能会对马的行为有很大影响，例如战马如果是黄色(绿色，哈哈)更利于伪装，此时"白"可能是一个很关键的问题，颜色会影响到不同的伪装策略，此时将白马作为马的一个子类则是必须的！所以问题域不同，类的设计就不同，生活中的问题域比较清晰(生物学家和厨师对马的理解不同)，而软件建模时往往问题域混杂，这也是OO设计时比较困难的问题，所以分析问题域也是非常重要的设计问题。

兼听则明 2006-01-19 14:16 发表评论

我来也

兼听则明 — Thu, 19 Jan 2006 06:05:00 GMT

过去一直在donews混迹，听朋友推荐，此处高手云集，我也来凑凑热闹。:-)

兼听则明 2006-01-19 14:05 发表评论