我爱oo,我爱java

合并前面所说的Item和ItemManager成为 domainItem,我认为贫血可以使,层次更清晰 ,便于模型维护

不敢苟同楼主的观点

ORA-00604: error occurred at recursive SQL level 1
ORA-12705: Cannot access NLS data files or invalid environment specified

ORA-00604: error occurred at recursive SQL level 1
ORA-12705: Cannot access NLS data files or invalid environment specified

请问这个如何解决啊 谢谢！！

对于字段数不是很多的表abator生成的xml文件包含insert update select 等方法。
而对于字段数很多的表，abator确只能生成resultMap和动态条件，其他的insert和update等都没有。请问这是为什么啊。

我也碰到过xml解析错误的现象。后来发现是ibatis的配置中没有打开namespace这个选项，要这样
<sqlMapConfig>
<settings
useStatementNamespaces="true"
/>
...
不知道你指的错误是不是类似的情况？

另外，我不太明白abator自动生成的xxxExample类和xxxselectByExample（）怎么使用，能贴一段示例代码吗？

期待您的回信：tedeyang@msn.com

典型的滥用接口

@andyking
<table schema="" tableName="dbo.user_property">
改成
<table schema="dbo" tableName="user_property">
试试

我看你的没什么问题

Generation Warnings Occured
Table dbo.user_property does not exist, or contains only LOB fields
请问大哥这是什么原因！明明数据库里面有这张表!为什么不能生成！

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE abatorConfiguration PUBLIC "-//Apache Software Foundation//DTD Abator for iBATIS Configuration 1.0//EN"
"http://ibatis.apache.org/dtd/abator-config_1_0.dtd">

<abatorConfiguration>
<abatorContext> <!-- TODO: Add Database Connection Information -->
<jdbcConnection driverClass="net.sourceforge.jtds.jdbc.Driver"
connectionURL="jdbc:jtds:sqlserver://localhost:1433/test;tds=8.0;lastupdatecount=true"
userId="sa"
password="">
<classPathEntry location="D:/tools/driver/jtds-1.2.jar" />
</jdbcConnection>

<javaModelGenerator targetPackage="com.ibatis" targetProject="." />
<sqlMapGenerator targetPackage="com.ibatis.sqlmap" targetProject="." />
<daoGenerator type="IBATIS" targetPackage="com.ibatis" targetProject="." />

<table schema="" tableName="dbo.user_property">
<generatedKey sqlStatement="SELECT @@IDENTITY as column_name" identity="true" column=""/>
</table>

</abatorContext>
</abatorConfiguration>

设计正方形为矩形的子类? 什么意思？

个人认为，只要明确了需求，设计正方形为矩形的子类还是不难的

dao层try一下，如果是有重复记录，就抛出checked exception（dao层公用的）,业务层捕获即可。

to pesome:
同意

抛出DataAccessException也不一定是非常严重的问题，更不表示系统已无法正常使用。说到底，先check还是抛错都是由成本决定，由出错的几率决定。

to yuxie:
如果数据库记录很多，checkUserExist()，成本很高，另外，如果有并发冲突时checkUserExist()将很可能失效。－－如你所说！

to 兼听则明:
很简单亚，你只要做一个checkUserExist()的方法就是了，如果返回true就throw exception。通过catch DataAccessException来判断是否用重复记录，我觉得不是一个好的方法。
数据库一旦发生异常，抛出DataAccessException，就应该是一个非常严重的错误，此时系统已无法正常使用，直接在表现层总的catch一下，给用户一个错误界面就ok了。
如果在checkUserExist()之后，两个用户同时插了相同的数据，这确实是个问题~欧没有想到好的方法

spring设计成runtime是合理的，而我们catch它的异常也是合理的

to yuxie:
你说的很对，Spring最好不要侵入我们的领域。

但对于 “addUser() 可以抛出UserExistException 比 主键冲突的 DataAccessException好的多” 问题，我们怎样才能处理到底是数据库连接异常，还是仅仅是重复UserID的输入错误(即主键冲突--业务主键)呢?

关于返回值得问题，我认为抛出Checked Exception作为返回值是业务层的事情，而我们说的底层的应用，是需要跟业务层松耦合的。如果底层（集成层等）抛出一个checked exception,你的业务逻辑层就必须要捕获它或者throw掉，这就增加了系统的耦合性。所以spring把大部分异常封装成runtime是有道理的。如果他不做成runtime的，你的业务层就必须import org.springframework.…….XXException,紧绑定在spring上，岂不是很郁闷！

checked exception可以替代返回值::确实如此，实际上业务异常是以返回值的身份出现的，更不该是"异常"，比如login()方法可能抛出 UnknownUserException,WrongPasswordException....
而 addUser() 可以抛出UserExistException 比 主键冲突的 DataAccessException好的多.

在充分设计和充分测试的情况下，这个问题可以被控制到很小的范围,但是谁能保证设计和测试足够"充分"呢？

to: yuxie

实际我都捕获了，并忽略了－－－－忽略也是一种“你说的恢复”,另外“不能被恢复的异常你要做成Runtime的”的问题在于现在Spring中把所有的异常都封装成Runtime的了－－－－当然，我们还可以通过捕获处理我们想处理的问题。

不能恢复就一定要做成runtime exception？without ejb还说checked exception可以替代返回值呢。要具体问题具体分析，不能太教条。

Road从来没有说过底层异常都封装成Runtime的，他的意思是不能被恢复的异常你要做成Runtime的（one-on-one那本书），像这个task的初始化，你捕捉了有什么用呢？异常还是已经发生了，而且没有被恢复！

to qiu:
然，Spring帮我捉了一只虫，
你是否感谢MS帮你捉了 其他软件的虫呢 －－－－－－－－写了半天帖子－－－系统崩溃，没能保存－－－－
在没有上线时，触发bug非常好！可是如果系统正式运行时发生的瘫痪级异常，作为软件开发者还会笑的出来吗？
－－－显然，使用某种通知机制通知管理员，由管理员来需求开发人员支持，好过使用系统宕掉的方式通知软件开发者....

to: 王麻子
我觉得你说的是对的，但是有时候需求并没有分析完全，在系统上线后才发生这个问题，即本该是“业务需求抛出一系列的应用异常.”但实际抛出了RuntimeException，我认为同样不该展现给客户“异样”的异常：
例：－－－－仅仅是例子！
我使用Qutarz作调度,当一个调度不能被fire时，它将抛出RuntimeException，我们的测试(案例)没有发现这个情况，到系统上线时，抛出异常，如果随便给客户一个"系统错误"，我认为是很不好的，因为客户会认为发生了很严重的错误，实际只是简单的输入错误而已，即按年调度，但在开始时间到结束时间端内没有该调度触发的时机。

to: darkbluefeeling
当然，如果重要的系统部分不能init成功，系统应该首先排错；但如果只是很小的一个部分不能init成功－－就造成系统不能启动,我认为是系统设计有问题。
比如：如果声卡驱动装载不成功，操作系统就不能启动，只是 "兰屏",你将大骂操作系统，而如果硬盘有故障，操作系统不能引导，则是骂不到操作系统。

测试只能证明系统有bug，不能证明系统没有bug。


不是应该感谢spring帮你找到了一个bug么?

不是表现层应该尽量捕获非业务的RuntimeException给最终用户更好的操作感受,,
而是业务逻辑层根据业务需求抛出一系列的应用异常.
如果表现层遇到了非应用异常的其它情况,就是编程错误,或系统错误.

我觉得初始化如果都出问题了，系统就应该halt了，把问题隐藏起来可比暴露出来问题多的多。毕竟是初始化，这儿不应该出问题的。

呵呵，真的不知呀，我随便想到瞎写的

这不是彦宏博士的东西了?

热烈欢迎