我是这样认识注解和XML的

在使用jpa时，比如我使用hibernate作为实现，默认情况下如果classpath下有bean validation实现会自动开启JSR-303验证。其通过Listener实现，即可以在如insert、update之前执行验证，如果验证失败会直接抛出验证失败异常。接下来可进行异常处理。

 

现在的问题是：

1、比如我们在Web层进行验证，如使用SpringMVC，此时我们可以直接在web层使用JSR-303验证，而且可以控制 什么时候需要验证；

2、当然也可以在业务逻辑层进行，这个可以参考Spring3.1 对Bean Validation规范的新支持(方法级别验证)；

3、现在jpa也支持验证实体。

 

所以此时如果不希望jpa进行验证，可以考虑使用如下代码进行关闭：

 

<!-- 使用自定义的validator进行jsr303验证 -->
<entry key="javax.persistence.validation.factory" value-ref="validator"/>
<!-- jsr303验证模式 因为其要么验证 要么不验证 不能按照规则走 所以此处禁用 -->
<entry key="javax.persistence.validation.mode" value="${javax.persistence.validation.mode}"/>

 

为什么jpa默认的实现不好呢？这里给大家举个例子：

发送消息：

标题：5-200个字符

内容：5-50000个字符

假设用户编辑了一个消息，此时用户在发送时突然有事要离开，这个时候发现内容还没写，要保存草稿，如果此时保存，会进行jpa的bean validation，此时肯定不通过，但是对于这种情景我们是不需要的。

 

因此这种注解的验证，只能满足大部分需求，如果一旦满足不了，连不想用都不行。即要么全用，要么全不用。即使用XML方式也会有这个问题。

 

解决方案：

应该提供一些开关数据来控制，改变那种要么全 要么无的方案。

 

但是bean validation也提供了分组的概念，即按组验证，但是这个对我们来说没有什么用处。

 

 <property name="javax.persistence.validation.group.pre-update"
                value="javax.validation.group.Default, com.acme.group.Strict"/>

 

具体可参考其官方文档：

http://docs.jboss.org/hibernate/orm/4.2/manual/en-US/html_single/#d5e9828 

 

 

而且现在注解使用的越来越广泛；它的主要好处是写起来比xml要方便的多，但是它们的目的都是一样的，元数据。

 

我的理解：

注解：是一种分散式的元数据，与源代码紧绑定。

xml：是一种集中式的元数据，与源代码无绑定。

 

因此注解和XML的选择上可以从两个角度来看：分散还是集中，源代码绑定/无绑定。

 

注解的缺点：

1、很多朋友比如在使用spring注解时，会发现注解分散到很多类中，不好管理和维护；这个其实要借助工具，我目前使用的是IDEA，它在这方面表现的非常好；当然现在还有Spring的STS，也是不错的； 所以借助工具，能解决这个问题；

2、注解的开启/关闭必须修改源代码，因为注解是源代码绑定的，如果要修改，需要改源码，这个有这个问题，所以如果是这种情况，还是使用XML配置方式；比如数据源；

3、注解还一个缺点就是灵活性，比如在之前翻译的Spring Framework 4.0 M1: WebSocket 支持；在实现复杂的逻辑上，没有XML来的更加强大；注解就是要么用，要么不用，比如之前的jpa bean validation，要么全，要么没；遇到这种情况很痛苦；

4、还一种就是约定大于配置，但是在处理一些复杂的情况下，注解还是需要的（如Spring的数据验证/数据绑定注解很强大）；

5、通用配置还是走XML吧，比如事务配置，比如数据库连接池等等，即通用的配置集中化，而不是分散化，如很多人使用@Transactional来配置事务，在很多情况下这是一种太分散化的配置；

6、XML方式比注解的可扩展性和复杂性维护上好的多，比如需要哪些组件，不需要哪些；在面对这种情况，注解扫描机制比较逊色，因为规则很难去写或根本不可能写出来；

 

 

注解的好处：

1、XML配置起来有时候冗长，此时注解可能是更好的选择，如jpa的实体映射；注解在处理一些不变的元数据时有时候比XML方便的多，比如springmvc的数据绑定，如果用xml写的代码会多的多；

2、注解最大的好处就是简化了XML配置；其实大部分注解一定确定后很少会改变，所以在一些中小项目中使用注解反而提供了开发效率，所以没必要一头走到黑；

3、注解相对于XML的另一个好处是类型安全的，XML只能在运行期才能发现问题。

 

注解也好，XML也好，我们还是需要一些开关/替换机制来控制特殊需求，以改变那种要么全部 要么没有的方案。。

 

还一种呼声就是约定大于配置，这种方案可能在某些场景下是最优的，但是遇到一些复杂的情况可能并不能解决问题，所以此时注解也是一个不错的方案。尤其在使用springmvc时，好处是能体会的出的。

 

不管使用注解还是XML，做的事情还是那些事情，但注解和XML都不是万能的，满足自己的需求且已一种更简单的方式解决掉问题即可。

 

就像探讨一下技术问题，很多人都带有很强的个人喜好来评判一个东西的好坏，这种探讨没有任何意义，我们最终的目的是解决方案，所以我们应该探讨的是能不能解决问题，能不能以更容易理解的方式解决问题，能不能更简单的解决问题。

 

不管是约定大于配置、注解还是XML配置也好，没有哪个是最优的，在合适的场景选择合适的解决方案这才是重要的。就像设计模式一样：是对特定环境中重复出现的特定问题的一个经过前人验证了的解决方案。

欢迎拍砖，探讨。

评论

17 楼 weibo227 2016-02-02  

gang.chen 写道

不太理解约定大于配置具体指什么

      举个例子，页面单独引了一个css，里面有个 .fontSize{font-size:15px;}，然后我再jsp中的标签内又使用了style='fontSize:18px;'    页面渲染的时候   会先读取css文件，最后再读取标签上自定义的样式，所以最后字体大小就变为18了，是18把之前加载的15替换了!!!

16 楼 gang.chen 2015-10-04  

不太理解约定大于配置具体指什么

15 楼 deyanglining 2015-07-17  

14 楼 jinnianshilongnian 2013-05-31  

witcheryne 写道

id.alex 写道

eric_hwp 写道

俺一直有个观点跟别人说，注解是Java代码，xml需要解析，那么xml要解析成Java需要一段时间，所以注解会比XMl快

注解是 java 反射去读, xml 是解析字符串读.
而且具体逻辑都不一定一样,没办法说谁快谁慢.
即使一样的逻辑两种方式速度的差距会小的可以忽略.

可以忽略不计。
如果应用的效率受这个影响，那上层代码也写的太牛了点。

用注解还是用xml配置。还是保持习惯比较好。
之前接触hibernate, spring 的时候，只有xml配置。
现在hibernate 还是使用xml配置 。
spring 的事务+数据源方面还是xml配置。

Spring Bean 大部分使用 @注解 + @Autowired
Rest-ful 接口方面用 JSR-RS 注解

现在还在用一个非常棒的注解工具:
lombok : http://projectlombok.org/

保持喜欢，工具各有利弊，是否用的好，在人...

+1

hibernate xml方式的一个缺点就是很多时候我们字段名和属性名是一样的，不能约定大于配置，如果选择注解时，是可以的。

还是得看使用场景

13 楼 witcheryne 2013-05-31  

id.alex 写道

eric_hwp 写道

俺一直有个观点跟别人说，注解是Java代码，xml需要解析，那么xml要解析成Java需要一段时间，所以注解会比XMl快

注解是 java 反射去读, xml 是解析字符串读.
而且具体逻辑都不一定一样,没办法说谁快谁慢.
即使一样的逻辑两种方式速度的差距会小的可以忽略.

可以忽略不计。
如果应用的效率受这个影响，那上层代码也写的太牛了点。

用注解还是用xml配置。还是保持习惯比较好。
之前接触hibernate, spring 的时候，只有xml配置。
现在hibernate 还是使用xml配置 。
spring 的事务+数据源方面还是xml配置。

Spring Bean 大部分使用 @注解 + @Autowired
Rest-ful 接口方面用 JSR-RS 注解

现在还在用一个非常棒的注解工具:
lombok : http://projectlombok.org/

保持喜欢，工具各有利弊，是否用的好，在人...

12 楼 id.alex 2013-05-31  

eric_hwp 写道

俺一直有个观点跟别人说，注解是Java代码，xml需要解析，那么xml要解析成Java需要一段时间，所以注解会比XMl快

注解是 java 反射去读, xml 是解析字符串读.
而且具体逻辑都不一定一样,没办法说谁快谁慢.
即使一样的逻辑两种方式速度的差距会小的可以忽略.

11 楼 eric_hwp 2013-05-31  

俺一直有个观点跟别人说，注解是Java代码，xml需要解析，那么xml要解析成Java需要一段时间，所以注解会比XMl快

10 楼 jinnianshilongnian 2013-05-31  

仔细去查阅了声明 和 配置：

声明式事务(declarative transaction management)是Spring提供的对程序事务管理的方式之一。
Spring的声明式事务顾名思义就是采用声明的方式来处理事务。这里所说的声明，就是指在配置文件中申明。用在Spring配置文件中声明式的处理事务来代替代码式的处理事务。这样的好处是，事务管理不侵入开发的组件，具体来说，业务逻辑对象就不会意识到正在事务管理之中，事实上也应该如此，因为事务管理是属于系统层面的服务，而不是业务逻辑的一部分，如果想要改变事务管理策划的话，也只需要在定义文件中重新配置即可；在不需要事务管理的时候，只要在设定文件上修改一下，即可移去事务管理服务，无需改变代码重新编译，这样维护起来极其方便。


声明式编程（英语：Declarative programming）是一种编程范型，采用了和命令式编程对立的方向。它描述目目标性质，让电脑明白目标是什么。
http://zh.wikipedia.org/zh-cn/%E5%AE%A3%E5%91%8A%E5%BC%8F%E7%B7%A8%E7%A8%8B

声明式也就是通过描述一些东西来完成一些目的，XML语言的作用也是描述数据的。

配置 -
布阵间棋子相互之间的配合，涉及棋子位置的高低、远近、疏密等方面。宋刘促甫《棋诀》：“远不可太疏，疏则易断；近不可太促，促则势赢。即指配置问题。
http://www.baike.com/wiki/%E9%85%8D%E7%BD%AE

声明可以认为是配置的一部分。

9 楼 jinnianshilongnian 2013-05-31  

一种根据不同环境选择不同配置的
spring profile

<beans profile="production">
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
         ……
</bean>
</beans>

<!-- local development环境 -->
<beans profile="development">
<context:property-placeholder location="classpath*:/application.properties,classpath*:/application.dev.properties" />

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<property name="driverClassName" value="${jdbc.driver}" />
<property name="url" value="${jdbc.url}" />
<property name="username" value="${jdbc.username}" />
<property name="password" value="${jdbc.password}" />
<property name="defaultAutoCommit" value="false" />
</bean>
</beans>


根据不同的环境选择不同的配置。

我习惯使用maven的profile。

8 楼 jinnianshilongnian 2013-05-30  

看的方面不同，可能理解上是不同；都是元数据 不知道有争议嘛。

7 楼 jinnianshilongnian 2013-05-30  

id.alex 写道

jinnianshilongnian 写道

是不是配置，关键看有没有人使用它 做事情。  

这么说也没有错.

可能我理解局限于"配置"这两个字上了.

就好像:
<dataSource />
不认为这是个配置,可以说是声明了一个数据源.

<dataSource>
<url value="..........">
</dataSource>
这个 url 才是配置,配置这个数据源的.

哈哈，这样理解也没错；如果把这个声明认为是配置呢？ 比如我们常用的web.xml，经常说的是部署个servlet，这里边的东西不都是配置吗？ <servlet>只是配置中的一个声明；为什么不把web.xml说成声明文件，而是部署描述文件/配置文件呢。  其实这种东西没有对错；如果刚开始大家把配置叫做声明不也一样嘛，关键点是认识到它的作用。

其实这篇文章里的关键点不是配置，而是元数据；即元数据是描述数据的数据，自身无作为，需要其他人解释它。所以注解也好，XML也好，都是同类。

6 楼 id.alex 2013-05-30  

jinnianshilongnian 写道

是不是配置，关键看有没有人使用它 做事情。  

这么说也没有错.

可能我理解局限于"配置"这两个字上了.

就好像:
<dataSource />
不认为这是个配置,可以说是声明了一个数据源.

<dataSource>
<url value="..........">
</dataSource>
这个 url 才是配置,配置这个数据源的.

5 楼 jinnianshilongnian 2013-05-30  

id.alex 写道

jinnianshilongnian 写道

注解也是一样配置；单独提取没有意义，因为不管是注解配置也好 XML配置也好，它们本身都是元数据， 数据本身不会自我解释，必须别人解释。所以两者的作用是一样；只是两种风格；

目前这种情况,这么说是没错,但为什么注解会称为配置呢,是因为注解的参数.

假如单独的一个 @Service 注解放在这里,其实根本的目标只是注释这个类是一个 Service
(请抛开 Spring 来看,哈哈.唠叨一些纯理念的东西), 但是 @Service(value="XXX") 就变成配置了.

jinnianshilongnian 写道

注解也是一样配置；

对于这句话的认识是,注解还是注解,但注解参数是配置.

请原谅我的较真,只是这么想的,说出来而已,也无意改变其他人的看法.

id.alex 写道

理念上的东西,较不得真.觉得合适就遵守,觉得不合适就按自己方式来.
只能统一目标,统一思想是基本不可能的事..

探讨问题就是这样，认识不同；我也很较真

@Service 如果不是配置；我们认为是注解；那它自己能单独工作吗？不能，需要别人读取它然后进行处理，所以是配置； 假设我写了个注解@AA，没人来处理它，是配置吗？不是，仅仅是个注解，因为没人处理它。


换句话说如
<bean ……>是配置吗？假设spring处理它 那么它就是配置； 假设我写了段：
<component……>，如果没有人处理它，是配置吗？不是，它仅仅是个无作为的数据。

是不是配置，关键看有没有人使用它 做事情。  

4 楼 id.alex 2013-05-30  

jinnianshilongnian 写道

注解也是一样配置；单独提取没有意义，因为不管是注解配置也好 XML配置也好，它们本身都是元数据， 数据本身不会自我解释，必须别人解释。所以两者的作用是一样；只是两种风格；

目前这种情况,这么说是没错,但为什么注解会称为配置呢,是因为注解的参数.

假如单独的一个 @Service 注解放在这里,其实根本的目标只是注释这个类是一个 Service
(请抛开 Spring 来看,哈哈.唠叨一些纯理念的东西), 但是 @Service(value="XXX") 就变成配置了.

jinnianshilongnian 写道

注解也是一样配置；

对于这句话的认识是,注解还是注解,但注解参数是配置.

请原谅我的较真,只是这么想的,说出来而已,也无意改变其他人的看法.

id.alex 写道

理念上的东西,较不得真.觉得合适就遵守,觉得不合适就按自己方式来.
只能统一目标,统一思想是基本不可能的事..

3 楼 jinnianshilongnian 2013-05-30  

id.alex 写道

注解:
注明解释. 修饰、辅助代码的作用,或者说,另外一种风格的代码.
重点是 做或不做

配置:
软件根据不同的环境,设置不同的配置,来带来最合适的表现.
重点是 怎样做.

约定:
在软件中,说白了就是默认配置.一般不需要关心,可以满足绝大多数的情况.
重点是 可以这样做.

注解也是一样配置；单独提取没有意义，因为不管是注解配置也好 XML配置也好，它们本身都是元数据， 数据本身不会自我解释，必须别人解释。所以两者的作用是一样；只是两种风格；

2 楼 id.alex 2013-05-30  

理念上的东西,较不得真.觉得合适就遵守,觉得不合适就按自己方式来.
只能统一目标,统一思想是基本不可能的事..

1 楼 id.alex 2013-05-30  

注解:
注明解释. 修饰、辅助代码的作用,或者说,另外一种风格的代码.
重点是 做或不做

配置:
软件根据不同的环境,设置不同的配置,来带来最合适的表现.
重点是 怎样做.

约定:
在软件中,说白了就是默认配置.一般不需要关心,可以满足绝大多数的情况.
重点是 可以这样做.