Dependency in JavaEE-dependency injection and javaee dependency Injection

Dependency in JavaEE-dependency injection and javaee dependency Injection

When a resource annotation prevents a field or a setter method, two things will happen. First, declare the resource reference (similar to the code example above) Just as it is placed on the bean class, and bind the resource name to the Environment naming context when creating the component. Second, the server automatically performs dependency search for you and sets the result to the instantiated class.

The process of automatically finding a resource and setting it to the class is called dependency injection because it is said that the server will inject the parsed dependency into the class. One of these technologies is usually called inversion of control, which eliminates the burden of manually searching resources from the context of the JNDI environment. Dependency injection is considered the best practice for application development, not only because it reduces the need for JNDI Lookup (and the related service locator mode), but also because it simplifies testing. No jndi api code in the class depends on the runtime environment of the application server. Therefore, the bean class can be directly instantiated in a unit test. Developers can manually provide the required dependencies and test the function of the class to be checked, without worrying about how to work around the jndi api.

Field Injection

The first form of dependency injection is called field injection ). Injecting dependencies to fields means that after the server finds dependencies in the Environment naming context, it directly assigns the results to annotation fields of the class. The following code re-examines the sample code from the above article and demonstrates the @ EJB annotation. This time, the result is injected into the audit field. In all the Directory Interface code we demonstrated earlier, the bean business method can be assumed that the AuditService bean reference is retained in the audit field.

(CODE)

Field Injection is of course the easiest way to implement. This form is used in the example of this book to save space. The only consideration for field injection is: if you are planning a unit test, you need to add a setter method or make this field accessible for your unit test to manually satisfy the dependency. Although free fields are valid, if there is no accessible method, an unpleasant hacker is required to set their values. If you do not want to add a setter Method for unit testing, consider the range of package for field injection.

As mentioned in the previous section, when a resource annotation is placed on a field or the setter method, a name automatically generated is referenced. For the sake of completeness, the format of this name is described here, however, you are unlikely to have many opportunities to use it. The generated name is completely limited to the class name, followed by a forward slash, followed by the name of the field or attribute. This means that if the AuditService bean is in persistence. in the session package, the injection EJB referenced in the above program is in "persistence. session. the environment naming context under the name of AuditService/audit will be accessible. Specifying the name element for the resource annotation overwrites this default value.

Setter Injection

The second form of dependency injection is called setterinjection. It involves annotation of a setter method instead of a class field. When the server parses the reference, it uses the query results to call the annotated setter method. The following code finally examines the above Code to demonstrate the use of setter injection.

(CODE)

This style injection allows private fields, but also applies to unit tests. Each test can simply instantiate the bean class and manually execute the dependency injection by calling the setter method. Generally, the setter method can be implemented to meet the resources required for the test.