12 best practices for summarizing XML configurations in spring

Spring is a powerful Java application framework that is widely used in Java applications. Provides enterprise-class services for Plainoldjavaobjects (POJOs). Spring uses a dependency injection mechanism to simplify work while improving testability. Springbeans and dependencies, as well as the services required for the beans class, are described in detail in the configuration file, which is a typical XML format. But it is both lengthy and impractical. It's hard to read and manage for big projects that need to define a lot of springbeans.

In this article, I'll show you 12 good practices for the Springxml configuration. Some of these practices are not only good practice, but also necessary practice. In addition, other factors, such as the design of domain models, can affect the configuration of XML, but this article focuses on the readability and manageability of XML configurations.

1. Do not use autowiring

Spring can automatically bind its dependencies through class introspection so that you do not have to specify the properties and constructors of the bean. The Bean's properties can be automatically bound by property name or type matching. The constructor implements automatic binding through type matching. You can even specify that automatic binding mode is automatically detected, and it can guide spring to choose an appropriate running mechanism. Let's take a look at one of the following examples:

class= "Com.lizjason.spring.OrderService" autowire= "ByName"

The property name of the OrderService class is used in the container to match the bean instance. Automatic binding can potentially save some typing and reduce some confusion. But in real-world engineering you should not use this approach because it sacrifices the clarity and maintainability of the configuration. Many of the guides and presentations tout automatic binding as an excellent feature of spring without mentioning the sacrifices of this feature. In my opinion, this is like the object-pooling in spring, which is more like a business feature to occupy more markets. It's a good way to compact XML configuration files, but it actually adds complexity, especially if you run a project with a large number of class declarations. Although spring allows you to mix automatic binding and manual binding, this paradox makes XML configuration more obscure.

2. Use of popular naming

This approach works just as well for Java coding. The use of clear, descriptive, and coordinated popular names in engineering is useful for developers to understand XML configurations. For example, for Beanid, you can name it according to the popular Java class name. For example, the Orderservicedao Beanid is named Orderservicedao. For large projects, you can prefix the Beanid with the package name.

3. Use a concise form

Simplicity avoids verbosity because it writes attribute values and references from child elements into attributes. For example, the following example:

Class= "Com.lizjason.spring.OrderService"

You can rewrite the above code in concise form to:

Class= "Com.lizjason.spring.OrderService

The concise form feature can be used in version 1.2. For no concise form.

Concise form not only can save your typing, but also make the XML configuration file clear. It is most noticeable when you have a large number of defined classes in a configuration file to improve legibility.

4. For constructor parameters, the type name is better than the sequence number.

When a constructor contains more than one parameter of the same type, or if the label of the attribute value is already occupied, spring allows you to use the ordinal number from the 0 count to solve these confusing problems. For example:

Class= "Com.lizjason.spring.BillingService"

as follows, it is better to write with type attributes:

class= "Com.lizjason.spring.BillingService" value= "name"

Using indexes can reduce some of the verbosity slightly, but it is prone to error and difficult to read compared to using type attributes. You should only use indexing when the constructor parameters are ambiguous.