Let's create a repository class to access our Product domain objects.

The most important step in the previous section is step 8, where we created the InMemoryProductRepository class. Since we don't want to write all the data retrieval logic inside the ProductController itself, we delegated that task to another class called InMemoryProductRepository. The InMemoryProductRepository class has a single method called getAllProducts(), which will return a list of product domain objects.

As the name implies, InMemoryProductRepository is trying to communicate with an in-memory database to retrieve all the information relating to the products. We decided to use one of the popular in-memory database implementations called HyperSQL DB; that's why we added the dependency for that jar in step 2. And in order to connect and query the HyperSQL database, we decided to use the spring-jdbc API. This means we need the spring-jdbc jar as well in our project, so we added that dependency in step 1.

Having the required dependency in place, the next logical step is to connect to the database. In order to connect to the database, we need a data source bean in our application context. So in step 3, we created one more bean configuration file called RootApplicationContextConfig and added two bean definitions in it. Let's see what they are one by one.

The first bean definition we defined in RootApplicationContextConfig is to create a bean for the javax.sql.DataSource class:

@Bean 
public DataSource dataSource() { 
   EmbeddedDatabaseBuilder builder = new EmbeddedDatabaseBuilder(); 
   EmbeddedDatabase db = builder 
         .setType(EmbeddedDatabaseType.HSQL) 
         .addScript("db/sql/create-table.sql") 
         .addScript("db/sql/insert-data.sql") 
         .build(); 
   return db; 
} 

In this bean definition, we employed EmbeddedDatabaseBuilder to build an in-memory database (HyperSQL) with a specified script file to create the initial tables and data to insert. If you watch closely enough, you can see that we are passing two script files to EmbeddedDatabaseBuilder:

So the next step is to create the specified script file in the respective directory so that EmbeddedDatabaseBuilder can use that script file in order to initialize the in-memory database. That's what we did in steps 4 and 5.

Okay, using the data source bean, we created and initialized the in-memory database, but in order to communicate with the database we need one more bean called NamedParameterJdbcTemplate; that is the second bean we defined in RootApplicationContextConfig. If you watch the bean definition for NamedParameterJdbcTemplate closely enough, you can see that we have passed the dataSource() bean as a constructor parameter to the NamedParameterJdbcTemplate bean:

@Bean 
public NamedParameterJdbcTemplate getJdbcTemplate() { 
   return new NamedParameterJdbcTemplate(dataSource()); 
} 

Okay, so far so good. We created a bean configuration file (RootApplicationContextConfig) and defined two beans in it to initialize and communicate with the in-memory database. But for Spring MVC to actually pick up this bean configuration file and create beans (objects), for those bean definitions we need to hand over this file to Spring MVC during the initialization of our application. That's what we did in step 6 through the DispatcherServletInitializer class:

@Override 
protected Class<?>[] getRootConfigClasses() { 
   return new Class[] { RootApplicationContextConfig.class }; 
} 

As I have already mentioned, we did all the previously specified steps in order to use the NamedParameterJdbcTemplate bean in our InMemoryProductRepository class to communicate with the in-memory database. You may then be wondering what we did in step 7. In step 1, we are just creating an interface called ProductRepository, which defines the expected behavior of a product repository. As of now, the only expected behavior of a ProductRepository is to return a list of product domain objects (getAllProducts), and our InMemoryProductRepository is just an implementation of that interface.

Why do we have an interface and an implementation for the product repository? Remember we are actually creating a Persistence layer for our application. Who is going to use our Persistence layer repository object? Possibly a controller object (in our case ProductController) from the Controller layer, so it is not best practice to connect two layers (Controller and Persistence) with a direct reference. Instead we can have an interface reference in the controller so that in future if we want to, we can easily switch to different implementations of the repository without making any code changes in the controller class.

That's the reason in step 9 that we had the ProductRepository reference in our ProductController not the InMemoryProductRepository reference. Notice the following lines in ProductController:

@Autowired 
private ProductRepository productRepository; 

Okay, but why is the @Autowired annotation here? If you observe the ProductController class carefully, you may wonder why we didn't instantiate any object for the productRepository reference. Nowhere could we see a single line saying something like productRepository = new InMemoryProductRepository().

So how come executing the line productRepository.getAllProducts() works fine without any NullPointerException in the list method of the ProductController class?

model.addAttribute("products", productRepository.getAllProducts() ); 

Who is assigning the InMemoryProductRepository object to the productRepository reference? The answer is that the Spring framework is the one assigning the InMemoryProductRepository object to the productRepository reference.

Remember you learned that Spring would create and manage beans (objects) for every @controller class? Similarly, Spring would create and mange beans for every @Repository class as well. As soon as Spring sees the annotation @Autowired on top of the ProductRepository reference, it will assign an object of InMemoryProductRepository to that reference, since Spring already created and holds the InMemoryProductRepository object in its object container (web application context).

Remember we configured the component scan through the following annotation in the web application context configuration file:

@ComponentScan("com.packt.webstore") 

And you learned earlier that if we configure our web application context with @ComponentScan annotation, it not only detects controllers (@controller), it also detects other stereotypes such as repositories (@Repository) and services (@Service) as well.

Since we added the @Repository annotation on top of the InMemoryProductRepository class, Spring knows that if any reference of the type productRepository has an @Autowired annotation on top of it, then it should assign the implementation object InMemoryProductRepository to that reference. This process of managing dependencies between classes is called dependency injection or wiring in the Spring world. So to mark any class as a repository object, we need to annotate that class with the @Repository (org.springframework.stereotype.Repository) annotation.

Okay, you understand how the Persistence layer works, but after the repository object returns a list of products, how do we show it in the web page? If you remember how we added our first product to the model, it is very similar to that instead of a single object. This time we are adding a list of objects to the model through the following line in the list method of ProductController:

model.addAttribute("products", productRepository.getAllProducts() ); 

In the previous code, productRepository.getAllProducts() just returns a list of product domain objects (List<Product> ) and we directly add that list to the model.

And in the corresponding view file (products.jsp), using the <C:forEach> tag, we loop through the list and show each product's information inside a styled <div> tag:

<c:forEach items="${products}" var="product"> 
<div class="col-sm-6 col-md-3" style="padding-bottom: 15px"> 
<div class="thumbnail"> 
      <div class="caption"> 
         <h3>${product.name}</h3> 
         <p>${product.description}</p> 
         <p>${product.unitPrice} USD</p> 
<p> Available ${product.unitsInStock} units in stock </p> 
      </div> 
   </div> 
</div> 
</c:forEach>

Again, remember the products text in the ${products} expression is nothing but the key that we used while adding the product list to the model from the ProductController class.

The for each loop is a special JavaServer Pages Standard Tag Library (JSTL) looping tag that will run through the list of products and assign each product to a variable called product (var="product") on each iteration. From the product variable, we are fetching information such as the name, description, and price of the product and showing it within <h3> and <p> tags. That's how we are finally able to see the list of products in the products web page.