annotation vs. xml

 
 
When using annotations you will reduce the amount of xml
instead of using XML for transactional management, marking a method as transactional with an annotation makes perfect sense, since this is information a programmer would probably wish to know.

There is a wider issue here, that of externalised vs inlined meta-data. If your object model is only ever going to persisted in one way, then inlined meta-data (i.e. annotations) are more compact and readable.

If, however, your object model was reused in different applications in such a way that each application wanted to persist the model in different ways, then externalising the meta-data (i.e. XML descriptors) becomes more appropriate.

Neither one is better, and so both are supported, although annotations are more fashionable. As a result, new hair-on-fire frameworks like JPA tend to put more emphasis on them. More mature APIs like native Hibernate offer both, because it's known that neither one is enough.

 

It depends on what everything you want to configure, because there are some options that cannot be configured with anotations. If we see it from the side of annotations:

  • plus: annotations are less talky
  • minus: annotations are less visible

It's up to you what is more important...

  • Server specific configuration (Like absolute paths to resources on server): Spring XML file
  • Injecting beans as members of other beans (or reusing a Spring XML defined value in many beans): Annotations

The key difference is that you don't have to recompile the code for all changing server-specific configurations, just edit the xml file. There's also the advantage that some configuration changes can be done by team members who don't understand all the code involved.

 
  1. Using "component-scan" to autoload classes which use @Repository, @Service or @Component. I usually give every bean a name and then wire them together using @Resource. I find that this plumbing doesn't change very often so annotations make sense.

  2. Using the "aop" namespace for all AOP. This really works great. I still use it for transactions too because putting @Transactional all over the place is kind of a drag. You can create named pointcuts for methods on any service or repository and very quickly apply the advice.

 
  • 1 Spring Stereotypes
  • 2 Spring MVC
  • 3 Spring Context Configuration
  • 4 Spring DAO
  • 5 Spring Transaction
  • 6 Spring Test
  •  

    Spring Stereotypes

    @Component

    @Controller

    @Repository

    @Service


    Spring MVC

    @Controller

    @InitBinder

    @ModelAttribute

    @RequestMapping


    Spring Context Configuration

    @Autowired

    @Scope


    Spring DAO

    @Repository


    Spring Transaction

    @Transactional


    Spring Test

    @ContextConfiguration

    @Rollback

    @TestExecutionListeners

     

    When using annotations you will reduce the amount of xml, the big drawback here is is that your configuration is scattered around all your classes. No central location for your configuration.

    When using xml it can become verbose, but you have 1 location to look for your configuration.

    So I tend to end up with a mixture of both. The coarse grained configuration is done in xml and the fine grained is done within the class. So that you have a somewhat reduced configuration and a central place for your main configuration and finer grained inside your classes
     
     
    Stereotype annotations are markers for any class that fulfills a role within an application. This helps remove, or at least greatly reduce, the Spring XML configuration required for these components. Specifically, the roles or stereotypes defined in Spring today include Repository, Service, and Controller
     
     
    The Four Types of Spring Stereotype Components and Their Purposes
    Stereotype Description Annotation
    Component: Generic stereotype @Component
    Repository: A class that serves in the persistence layer of the application as a data access object (DAO), otherwise known as a repository in some other technologies @Repository
    Service: A class that is a business service façade, often providing some reusable business processing @Service
    Controller: A controller component in the presentation layer of the application, as it relates to a MVC-designed application @Controller

    Per the Spring documentation, in addition to simplifying configuration and wiring, stereotype annotations make your application components "more properly suited for processing by tools or associating with aspects."

     

     

     

    Since Java adopted annotations, I’ve heard a lot of discussion around whether to prefer annotations over external configuration files (often XML) and vice versa.

    I think the decision boils down to two criteria:

    1) Can annotations simplify the metadata?
    2) Can changes to the metadata break behavior in your application?

    If annotations do not reduce the amount of metadata that you have to provide (in most cases they do), then you shouldn’t use annotation.

    I think the more important thing to considered is whether a configuration change could break behavior or not. If not, then you can feel comfortable applying the change while the system is running in production. External config files are the best place for the metadata in this case because you don’t want to have to recompile your code to make the change.

    However, if a metadata change could break behavior then you’ll want to test the change by going through a full release cycle (change code, build, test, deploy). If you’re going to go through a full release cycle there is practically no benefit to not recompiling besides the 5-10 seconds you save in compile time. The more important thing to consider is which method of metadata definition is simpler.

    For example, Hibernate mappings are often in XML, but annotations often provide the ability to specify the same mappings with significantly less metadata. Any changes you make to your mappings (whether in XML or annotations) could potentially be behavior breaking. You’re not going to change your mappings dynamically at runtime, are you? So, annotations seem like a much better choice.

    [Note: I might consider using XML metadata for Hibernate when mapping to a legacy database because the annotations can often become bulky. Also, you are forced to use XML if you want to map the classes against two different databases with different schemas. I haven't heard of a way to specify two mutually exclusive sets of Hibernate annotations on my classes. Even if this did exist it would be complex, which violates my first criterion for selecting annotations over XML

     

    Comments