Announcement Announcement Module
Collapse
No announcement yet.
annotation vs. xml Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • annotation vs. xml

    HI when would annotation actually be good. When would using xml configuration be beneficial.

    Is it good to have mixed or not. Is the rule never use xml configuration good or never use annotation good.

    Thanks

  • #2
    Originally posted by cablepuff View Post
    HI when would annotation actually be good. When would using xml configuration be beneficial.

    Is it good to have mixed or not. Is the rule never use xml configuration good or never use annotation good.

    Thanks
    Hi cablepuff, I am not actually expert on spring, however my opinion on that is annotation just helps the developer to reduce the usage of xml config files and that may be a benefit. I hope it helps.

    Comment


    • #3
      Both have their uses, both have pros and cons and a lot depends on personal preference.

      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. For me it works.

      For making your configuration clear also tools like Spring IDE can really help.

      Comment


      • #4
        thanks.

        HOw about in terms of using hibernate search which supports using annotations only? Would that count as "fined grained".

        Comment


        • #5
          Personally, I avoid annotations. In the purest of POJO designs, using an annotation couples that source file to the provider of the annotation. The config file approach, while perhaps being slightly more effort to maintain, preserves the POJO in that your source code has no direct coupling.

          Comment


          • #6
            Originally posted by Jabberz View Post
            Personally, I avoid annotations. In the purest of POJO designs, using an annotation couples that source file to the provider of the annotation. The config file approach, while perhaps being slightly more effort to maintain, preserves the POJO in that your source code has no direct coupling.
            I strongly agree with this point. Furthermore a centralized location of configuration is important to me.
            In some cases though maybe annotations fit better.
            I see there is a @Controller annotation in spring 2.5.x but I have not gone through it yet. While annotating your services and domain layer is invasive, annotating controllers is ok since they are already framework dependant.

            Comment


            • #7
              Originally posted by gregd View Post
              I strongly agree with this point. Furthermore a centralized location of configuration is important to me.
              In some cases though maybe annotations fit better.
              I see there is a @Controller annotation in spring 2.5.x but I have not gone through it yet. While annotating your services and domain layer is invasive, annotating controllers is ok since they are already framework dependant.
              I tend to agree with this, I'm not a huge fan of having configuration annotations in service and domain layers, primarily because it makes it more difficult for applications to change the behaviour of the service layers they are using.

              That said, I still find annotations useful in those layers - mostly as markers which are used by the application. For example marking certain methods on a service with a "cachable customer data" annotation, or a "invalidates customer cache" annotation. The decision about whether to do any caching, and how it is performed, is up to the application but there is an easy way of adding caching to the service layer.

              Comment


              • #8
                Originally posted by Marten Deinum View Post
                Both have their uses, both have pros and cons and a lot depends on personal preference.

                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.
                Totally agree with this, its really useful to be able to reference a single location to get the bigger picture about your application flow and basic 'plumbing'.

                Originally posted by Marten Deinum View Post
                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. For me it works.

                For making your configuration clear also tools like Spring IDE can really help.
                I think viewnames for controllers (e.g. formView, successView and so on) come under configuration as well and for goods reasons, for instance if you need to reuse the logic in a given controller for presenting different views and the fact that you dont want to hardcode the flow of the application in your code.

                Specifying viewnames in spring config was done by convention before the introduction of Annotated controllers in 3.0 because the good old Abstract Controller classes sort of 'advised' us to do so along with some other stuff. However after the advent of Annotated controllers, a lot of the 'guiding principles' (some viewed these as constraints) are gone with the abstract controllers getting deprecated in 3.0.

                For people who despise XML configuration annotations is seen as the way to go to get to this utopia zero XML config controller configuration, and in getting to this the tendency is to hardcode things like viewnames in the controllers just to get away with not having it in configuration which I think is wrong as you are taking away the flexibility of your application just to save a handful of XML config.

                Any thoughts?

                Comment


                • #9
                  I prefere annotations as it is clearer and you have the information right there where the code is as well - so i feel its easier to maintain. However annotations have the drawback that you can't change them without recompiling the code. So if you have settings that need to be configured at install time e.g. performance tuning etc. then xml configuratio might be the better choice.

                  Comment


                  • #10
                    Annotations should be used for the metadata that is rarely going to change and xml should be used for the configuration that needs to be changed frequently.I believe that most of the data we puts in xml is rarely needs to be changed and hence they are better to be put as annotations.Therefore,in spring version 3.0,the @Configuration,@Bean annotations is introduced to rid off from the xml.

                    Comment


                    • #11
                      Originally posted by zzkhan View Post
                      I think viewnames for controllers (e.g. formView, successView and so on) come under configuration as well and for goods reasons, for instance if you need to reuse the logic in a given controller for presenting different views and the fact that you dont want to hardcode the flow of the application in your code.

                      Specifying viewnames in spring config was done by convention before the introduction of Annotated controllers in 3.0 because the good old Abstract Controller classes sort of 'advised' us to do so along with some other stuff. However after the advent of Annotated controllers, a lot of the 'guiding principles' (some viewed these as constraints) are gone with the abstract controllers getting deprecated in 3.0.

                      For people who despise XML configuration annotations is seen as the way to go to get to this utopia zero XML config controller configuration, and in getting to this the tendency is to hardcode things like viewnames in the controllers just to get away with not having it in configuration which I think is wrong as you are taking away the flexibility of your application just to save a handful of XML config.

                      Any thoughts?
                      I agree
                      I tend to use annotations only to avoid the dependency of the mvc class itself. I still prefer the xml configuration since I find many places where a single controller class is configured differently for serving different cases. Furthermore this framework-independance allows me to have some base functionality classes that can be extended by my controllers no matter if they are SimpleForm or ParametrizableView style or whatever. Untill 2.5 I had to use some type of delegation pattern for these cases but no more...
                      I still believe though that new Spring users should have a look at the javadocs of the -now deprecated- controllers (especially AbstractFormController) to have a basic idea of how things are handled under the covers

                      Comment


                      • #12
                        Originally posted by Jabberz View Post
                        Personally, I avoid annotations. In the purest of POJO designs, using an annotation couples that source file to the provider of the annotation. The config file approach, while perhaps being slightly more effort to maintain, preserves the POJO in that your source code has no direct coupling.
                        I concur with this point. Despite many peoples adversion to xml config (or any external config) I find it better to decouple from code as much as possible with frameworks and true config type data. Now, annotations that are part of the base language structure I use including ones that allow injection of Spring items. In addition, having all your config / injection in one place allows for easy knowledge of where a bean is used.

                        Another place where I often 'violate' this standard is in JUnit tests where I annotate injection more to save on test specific config. At least so far that has not been a 'bad' thing.

                        Comment


                        • #13
                          And annotations are especially convenient to configure beans of 3rd-party classes .

                          Originally posted by darted View Post
                          I concur with this point. Despite many peoples adversion to xml config (or any external config) I find it better to decouple from code as much as possible with frameworks and true config type data. Now, annotations that are part of the base language structure I use including ones that allow injection of Spring items. In addition, having all your config / injection in one place allows for easy knowledge of where a bean is used.

                          Another place where I often 'violate' this standard is in JUnit tests where I annotate injection more to save on test specific config. At least so far that has not been a 'bad' thing.

                          Comment

                          Working...
                          X