Basic Concepts
Template Pattern
One of the very common patterns that you could across the Spring Framework is this behavioral pattern, also known as Template Method Pattern.
A template method defines the program skeleton of an algorithm. One or more of the algorithm steps can be overridden by subclasses to allow differing behaviors while ensuring that the overarching algorithm is still followed. By doing so, Spring gives the developers productivity gain and ease of use. It also abstracts and hides complex logic away from developers. It also avoids developers to do repeated steps (boiler plate) and concentrate on the core business logic in an application.
This pattern is used to:
- Avoid code duplication by implementing whichever is absolutely required in an algorithm
- Allows subclasses to implement behavior which varies according to implementation
- Controls at what points the subclasses can change the behavior
Typical real-life example of this design pattern is shown below:
Figure 16 Real-life example of Template Pattern
Repository Pattern
A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection. Client objects construct query specifications declaratively and submit them to Repository for satisfaction. Objects can be added to and removed from the Repository, as they can from a simple collection of objects, and the mapping code encapsulated by the Repository will carry out the appropriate operations behind the scenes. Conceptually, a Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer. Repository also supports the objective of achieving a clean separation and one-way dependency between the domain and data mapping layers.
– Martin Fowler
A Repository is a Domain-Driven Design concept but it is also a standalone pattern. Repositories are an important part of the domain layer and deal with the encapsulation of objects persistence and reconstitution. In the Repository pattern all of the data access is put in a separate class and is accessed via instance methods. By doing this data access is now encapsulated in a separate class, leaving the business object to get on with business. This stops the unfortunate mixing of data access and business logic. The repository pattern is very good in testing aspect. It’s simple to put an interface on the repository, and then for testing, replace with a fake repository during the unit test phase. So the big advantage of the repository is its inherent testability.
Figure 17 Typical Repository Pattern based on ideal DDD concept
Here, JdbcCustomerRepository is the bridge between the domain object Customer and the production database. The implementation of repository, CustomerRepository can be changed at will without any issues as it is completely independent from rest of the objects. The above is the perfect way of realizing Domain Driven Design concept. In our sample application we haven’t used the pure DDD approach.
DAO Vs Repository in your Spring Application
Explaining in simple terms, Data Access Object (DAO) is an abstraction of data persistence and Repository is an abstraction of a collection of objects.
In other words, DAO would be considered closer to the database, often table-centric and Repository would be considered closer to the Domain, dealing only in Aggregate Roots. A Repository could be implemented using DAO’s, but you wouldn’t do the opposite.
A Repository is generally a narrower interface. It should be simply a collection of objects, with a get, find and add entity method. A method like Update is appropriate on a DAO, but not a Repository.
According to me, it’s very difficult or hard to prefer one over the other. In the sample application I have used the Repository pattern but I cannot say with my experience that repository pattern is the right way and DAO pattern is the wrong way of coding. The discussion could go on and on, but let’s focus on the Spring Framework concepts.
JSR-250
Its Java Specification Request aimed at objective to develop annotations. It was envisioned that various JSR’s would use annotations to enable declarative style of programming. It provides a set of common annotations to be used in a JEE application. Spring has its own annotations, which will be discussed as and when required in this book. JSR-250 helps in preventing outburst of annotations by various Frameworks in markets and is very important that we have a good understanding of this before we dive deep into the Spring Framework. Since it’s in JEE specification, it facilities portability. All annotations reside in javax.annotation package. It’s included in starting from JDK 6 and as part of javaee-api for Java 5. Explaining JSR-250 will be out of scope for this book, but some well known annotations in this package include:
@PostConstruct
The PostConstruct annotation is used on a method that needs to be executed after dependency injection is done to perform any initialization. Only one method can be annotated with this annotation.
@PreDestroy
The PreDestroy annotation is used on methods as a callback notification to signal that the instance is in the process of being removed by the container. The method annotated with PreDestroy is typically used to release resources that it has been holding
@Generated
The Generated annotation is used to mark source code that has been generated. It can be specified on a class, methods or fields. It can also be used to differentiate user written code from generated code in a single file.
@Resource
The Resource annotation is used to declare a reference to a resource. It can be specified on a class, methods or on fields. When the annotation is applied on a field or method, the container will inject an instance of the requested resource into the application when the application is initialized. If the annotation is applied to a class, the annotation declares a resource that the application will look up at runtime.
Important annotations inside the package javax.annotation.security include:
@RunAs
The RunAs annotation defines the role of the application during execution in a Java EE container. It can be specified on a class. This allows developers to execute an application under a particular role.
@RolesAllowed
The RolesAllowed annotation specifies the security roles permitted to access method(s) in an application. The value element of the RolesAllowed annotation is a list of security role names. The RolesAllowed annotation can be specified on a class or on method(s). Specifying at the class level means that it applies to all the methods in the class. Specifying at the method means that it is applicable to that method only. If applied at class and method level, the method value overrides the class value.
@PermitAll
The PermitAll annotation specifies that all security roles are allowed to invoke the specified method(s), that is, that the specified method(s) are “unchecked”. It can be specified on a class or on methods. Specifying at the class means that it applies to all methods of the class. If specified at the method level, it only affects that method.
@DenyAll
This annotation specifies that no security roles are allowed to invoke the specified method(s), that is, that the method(s) are to be excluded from execution in the Java EE container
@DeclareRoles
This annotation is used to specify the security roles by the application. It can be specified on a class. It typically would be used to define roles that could be tested (i.e., by calling isUserInRole) from within the methods of the annotated class. It could also be used to declare roles that are not implicitly declared as the result of their use in a RolesAllowed annotation on the class or a method of the class.
JSR-330
The JSR was developed together by Google (Guice Framework) and SpringSource (Spring Framework) and is finally approved since late 2009. It defines a collection of annotations which are used to define dependencies and their providers and scopes within a compliant application or framework. Spring is valid JSR-330 implementation.
There are some overlaps between Spring and JSR 330 annotations which is explained in a brief manner as below.
JSR-330 annotation @Inject is analogous to Spring’s @Autowired annotation. For Spring to inject dependencies annotated with @Inject as it does dependencies annotated with @Autowired, it is a simple matter of instantiating an AutowiredAnnotationBeanPostProcessor, provided out of the box by Spring, and passing the javax.inject.Inject class name to its setAutowiredAnnotationType() method.
Technically speaking JSR-330 annotation @Qualifier is analogous to Spring’s @Named annotation. In JSR-330, @Named is a certain type of @Qualifier, and is analogous to Spring’s own @Qualifier annotation. For Spring to inject dependencies annotated with @Named as it does dependencies annotated with @Qualifier, it is a simple matter of instantiating a CustomAutowireConfigurer, provided out of the box by Spring, and passing a Set including the javax.inject.Named class name to its setCustomQualifierTypes() method. This tells Spring to treat @Named-annotated entities as it does @Qualifier-annotated entities. The below tables gives the comparison between various annotations in a summarized and easy format:
| Javax.inject.* (JSR-330) | Spring annotation |
| @Inject | @Autowired |
| @Named | @Component, @Qualifier |
| @Scope | @Scope |
| @Singleton | @Scope(“singleton”) |
Summary
In this chapter, I have presented you with information using which you can get up and running with Spring. I gave you information on the Spring packaging aspects and the dependencies required to run you application using Spring. I also gave the details of the sample application which will be used throughout the book to run you through the various concepts in the Spring Framework. In the subsequent chapter, we will be diving deep into the Spring Framework with the help from our sample application as well as de-facto Spring application development tool, STS.
Page Visitors: 7824
Tomcy John
Latest posts by Tomcy John (see all)
- A Guide to Continuous Improvement for Architects - February 2, 2023
- Cloud-first Architecture Strategy - January 26, 2023
- Architecture Strategy and how to create One - January 24, 2023