You are currently viewing Building a Trading Platform – Part 6: Adding demo data

Building a Trading Platform – Part 6: Adding demo data

We have a running application set-up, a database connection established, and our project has a scalable structure for development. Now it is time to bring our application to life by adding records to our database using Spring Boot. We will also generate demo data in Spring Boot, using the CommandLineRunner functional interface.

Why generate demo data?

There are two main reasons why we would want to generate demo data programmatically using Spring boot. For one, it allows us to do what the name already implies: demonstrate the functionality of the app. More importantly however, the generation of demo data using code works like an integration test, ensuring all functionality required to generate that demo data, works as expected.

What we will do

We will start by creating a Java class called “Log”. The class will be annotated as an “@Entity”, which triggers Spring Boot to generate a table. Using a repository and a service, we will enable the selection and addition of new records in that table. Finally, we will put a process in place, that triggers Spring Boot to add records to the table as part of the demo data creation upon application start-up.

Create a table

The first step is to create an entity that will serve as the basis to generate a table later on. An entity is simply a POJO class with annotations. Our class will have 3 attributes and a table annotation, defining the table name. The object will eventually look like this. Getters and setters have been omitted in the screenshot for the sake of readability.

The required imports for the annotations originate from

  • persistence
  • validation and
  • hibernate.annotations

If we run the application now, we will be able to see the newly created table in SQL Developer or MySQL workbench. Of course we have not yet created any data, so the table will be empty as well.

Adding a repository

Once we have generated the table, we would like to execute queries that generate, modify, and read data from the table. We would also like to avoid writing any SQL at all, since it is a hassle to read and write. This is where JPA Repositories come in. JPA repositories are powerful interfaces that are ultimately an extension of CRUD repositories. Diving into the full details and functionality would vastly exceed the scope of this article, but it boils down to writing method names in the interface following a set of conventions. The method names later get interpreted as SQL queries which are executed wherever we use the interface. A picture speaks more than a thousand words, let us have a look at how such a repository would look like in our case:

The screenshot shows one method name. As You can see, there is no need to even explain what the function does, because the declaration describes precisely what the function does, which parameters it uses and what is returns.

Of course, this one method is not all this interface provides. The JpaRepository it extends also provides a multitude of methods, like “findAll()”, “save()” or “findById()”.

Building a Service

Now that we have our repository, there are two ways we could proceed. We could either call the repository methods in the Controller directly, or we can wrap the methods in a service. There are arguments to be made for both strategies. In our case, we will choose to use wrapper methods in a Service class, to stick with the multilayer architecture we discussed in the previous article.

Lets look at the service. In line 15, the class imports the LogRepo class using the “@Autowired” annotation. The annotation indicates a Spring Dependency Injection, that “allows Spring to resolve and inject collaborating beans into our bean.”  That is, it instantiates the LogRepo when necessary, so we can access its functionality.

After the dependency injection, we have three methods. One instantiates a Log object and saves it using the save method from the repository interface. The other two are wrapper functions, as described before.

Generating demo data

We built the entity to define a table, created a bean to enable communication with the persistence layer and added a service to implement a business logic. Now it is time to test our work by executing the code. To do that, we create an “@Component” class that contains the methods to generate the demo data. The class will simply be called “DemoDataLoader”. It “writes” into the log by creating an log object and saving it to the database, the way we implemented that functionality in the service bean. Afterwards, it retrieves that record by calling “getAll()” and iterates over the list of results, printing out all log messages.

Now that the implementation of the demo data creation is done, we add an “@Bean” method with the return type CommandLineRunner to the entry point of our application. The method will take the DemoDataLoader component class as a parameter and return the execution of the demo data creation method as an argument:

Well done! We can now run the application and will get the following output:

The example we examined here is very simple but shows how we can write to the database as part of the application start-up and retrieve that created data to verify everything works as expected. Of course the testing of our applications functionality should also be done using unit tests and other similar tools. However, this approach enables a testing strategy that is less “sterile” closer to a real world application scenario, assuming that it will be implemented in an orderly fashion.

Leave a Reply