Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>After reading some related posts here and having further discussion in the team we come to the following conclusions. I hope the would be useful to others here.</p> <p><strong>About XML configuration</strong> (which we are using up to now), we decided to keep it for dependencies that are for libraries (being either developed by us, or by third parties). Libraries by definition should provide certain functionality only and can be used in various scenarios, which may not always involve DI. Therefore using annotations in our library projects will bring dependencies of the DI framework (Spring in our case) to the library, and this would be useless when the library is used without DI. Having extra dependencies is not considered a good practice among our team (an in general IMHO). When we are assembling an application, the application has the needed DI dependencies and the injection of library classes is done by configuration. XML is also good for providing mock implementations for many components, without recompiling the modules that will use them. This gives us flexibility when testing or running in local or production environment.</p> <p><strong>About annotations</strong>, we actually decided that we can benefit using them when the injected components will not vary, t.e. there will not be scenarios where different implementations of a component would be used. We decided that annotations will be very useful for small modules/applications with clear functionality, that will not change or support different implementations. Such modules we can almost use out of the box in different projects, without writing the tedious XML. However, we agreed that these modules should have the dependencies described in our technical documentation, so that when assembling the entire application, one can have an idea of these dependencies without scrolling through the code, or even loading the module in the IDE. Still, it seems that annotations will require the module to be somewhat mature about what dependencies it will use. This is also applicable for the java class configurations, which is the modern Spring alternative of XML contexts.</p> <p>In general if our dependencies may vary for different scenarios, or a module can be used with different components, we decided to keep the XML and not to hard-code any dependencies in such module. Clearly, there MUST be a <em>right</em> balance between both approaches, and a clear idea for the usages.</p> <hr> <p>An important update regarding the mixed approach. Recently we had a case with a test framework we created for our QA team, which required dependencies from another project. The framework was designed to use the annotation approach and Spring configuration classes, while the referenced project has some xml contexts that we needed to reference. Unfortunately, the test classes (we used org.testng with spring support) could only work with either xml or java configuration classes, not both. </p> <p>This situation illustrates a case where both approaches would clash and clearly, one must be discarded. In our case, we migrated the test framework to use spring xml contexts, but other uses could imply the other way around.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload