注解POJO比不上使用配置文件的地方

1、跨数据库，POJO将无法公用
使用注解方式的POJO，将会使POJO变成了hibernate私有品，如果ID上使用SEQUENCE等某个数据特有的生成方式，当需要将这个POJO作为公共包提供给其他项目公用时，而那个项目又使用了另外一种数据库，这就导致要修改POJO，也就是POJO公用失败，修改POJO还可能导致dao甚至service的修改。

2、注解不集中，管理没有XML方便
    个人建议，系统的所有POJO单独放到一个目录下，这个目录只放POJO，不放任何其他的DAO,SERVICE等，这个目录下再细分各个模块来放各个模块的POJO

3、代码不美观

4、不适合换框架
    我们项目就是了，服务端用了ORACLE，客户端有mysql，服务端用了hibernate，运行一段时间后，方向hibernate效率有问题，想换成ibatis的，但是POJO中到处是注解，很无语

请问lz，你hibernate换成了ibatis，难道dao层不换？
lz肯定也没有用过 pojo的 验证注解。
当你从java 1.3走过来的时候，你就知道现在的注解有多少的方便。

估计楼主说的是hibernate注解，JDK的注解当然ok，碰到第三方的注解的确会比较麻烦，代码倾入性太强。
当然，如果确定了使用某第三方产品，那也无所谓了，不过若是没有确定的话，还是别用注解为妙。

汗...........
hibernate走jpa的注解不就好了。貌似现在生成器生成的就是jpa的注解。
我还希望 ibatis 的新版本什么时候也能支持 jpa的注解，这样就省去了resultMap的xml文件。

anotation的使用天生就带有侵入性，依然还是一个取舍的问题。

为什么一定要用hibernate的anotation？

直接用JPA不用好了。

感觉有些吹毛求疵的!注解比xml方便之处在于
A  维护一个文件,xml需要同时维护xml和java两个,修改了java直接生效,在很频繁修改po的情况下,省去了修改两处的麻烦
B  注解修改规则代码量小,hibernat来说,从oneTomany 到manytomany很容易找到,利用ide的导航功能,很容易找到修改的地方,xml则需要用肉眼查找,如果你说没有全局性,那么设计期的uml类图更有全局性
C 注解很方便在一个po上进行多项功能的标记,比如在一个属性上,我既可以标注持久化,也可以标注为远程调用,也可以标注为luncune索引,亦可以标注数据验证,请问这种场合xml何解呢
D 注解利用了oo特性,具有继承功能,可以高度重构,把公用的注解配置在一个父类上,代码简洁高效,xml呢,所有的xml配置不一定都支持继承特性

暂时就想到这么多了..............................................

JPA annotation.

+1  用jpa的注解

jpa 才是真正的鸡肋

想做老大 却懒得总结和抽象各ORM，