Click here to Skip to main content
Click here to Skip to main content
Go to top

Java Spring Mvc Single Page App with Upida (Backend)

, 3 Mar 2014
Rate this:
Please Sign up or sign in to vote.
Web development using JSON is simple

Introduction

Let's try to create a simple web application using the most modern technologies and see what problems we may face. I will use the latest Spring MVC and latest Hibernate. I am going to use Spring Mvc JSON API to its full potential - i.e., all interactions between browser and server will go asynchronously in JSON. In order to accomplish this, I am going to use JavaScript library - AngularJS. But it is not a big deal if you prefer KnockoutJS.

Note, this article is about backend only. If you are curious about front-end side, then follow this link: Java Spring Mvc Single Page App with Upida (Frontend/AngularJS).

Let's imagine we have a simple database with two tables: Client and Login, every client can have one to many logins. My application will have three pages - "list of clients", "create client", and "edit client". The "create client" and the "edit client" pages will be capable of editing client data as well as managing the list of child logins. Here is the link to the resultant web application.

First of all, let's define the domain (or model) classes (mapping is defined in hbm files):

public class Client {

    private Integer id;
    private String name;
    private String lastname;
    private Integer age;
    private Set<Login> logins;

    /* getters and setters go here */
} 

public class Login {

    private Integer id;
    private String name;
    private String password;
    private Boolean enabled;
    private Client client;

    /* getters and setters go here */
}

Now, I can create Data-Access layer. First of all, I must have base DAO (and interface) class which is injected with Hibernate SessionFactory, and defines basic DAO operations: Save, Delete, Update, Load, Get, etc.

public interface IDaobase<T> {

    void save(T item);
    void update(T item);
    void merge(T item);
    void delete(T item);
    T get(Serializable id);
    T load(Serializable id);
} 

And here is the Daobase class:

public class Daobase<T> implements IDaobase<T> {

    private SessionFactory sessionFactory;
 
    public Daobase(SessionFactory sessionFactory) {

        this.sessionFactory = sessionFactory;
    }
 
    protected Session session() {

        return this.sessionFactory.getCurrentSession();
    }

    @Override
    public void save(T entity) {

        this.session.save(entity);
    }

    @Override
    public void update(T entity) {

        this.session.update(entity);
    }
 
    /* others basic methods */
}

I will have only one DAO class - ClientDao.

@Repository
public class ClientDao extends Daobase<Client> implements IClientDao {

    @Autowired
    public ClientDao (SessionFactory sessionFactory) {

        super(sessionFactory);
    }

    @Override
    public Client getById(int id) {

        Query query = this.session().createQuery("from Client client left outer join fetch client.logins where client.id = :id");
    query.setParameter("id", id);
    query.setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY);
    return (Client)query.uniqueResult();
    }

    @Override
    public List<Client> GetAll() {

        Query query = this.session().createQuery("from Client client left outer join fetch client.logins");
        query.setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY);
        return query.list();
    }
}

When DAO is done, we can switch to Service layer. Services are usually responsible for opening and closing transactions. I have only one service class. It is injected with respected DAO class.

Note, the save() and update() methods accept a Client object and its child Logins, and therefore perform save or update operations, using Hibernate cascading (persisting parent and children at the same time).

@Service
public class ClientService implements IClientService {
    private IClientDao clientDao;
 
    public ClientService(IClientDao clientDao) {

        this.clientDao = clientDao;
    }

    @Override
    @Transactional(readOnly=true)
    public Client getById(int clientId) {

        Client item = this.clientDao.GetById(clientId);
        return item;
    }

    @Override
    @Transactional(readOnly=true)
    public List<Client> getAll() {

        List<Client> items = this.clientDao.getAll();
        return items;
    }

    @Override
    @Transactional
    public void save(Client item) {

        /* TODO: assign back-references of the child Login objects -
           for each Login: item.Login[i].Client = item; */
        this.clientDao.save(item);
    }

    @Override
    @Transactional
    public void update(Client item) {

        Client existing = this.clientDao.load(item.getId());
        /* TODO: copy changes from item to existing (recursively) */
        this.clientDao.merge(existing);
    }
}

Let's talk a bit about controller. I am going to have a controller class which has two responsibilities. Firstly it maps incoming URL text to corresponding HTML view. And secondly, it is responsible to handle REST service calls from javascript. Here is how it looks:

@Controller
@RequestMapping({"/client"})
public class ClientController {

    private IClientService clientService;

    @Autowired
    public ClientController(IClientService clientService) {

        this.clientService = clientService;
    }

    @RequestMapping(value={"/list"})
    public String list() {

        return "client/list";
    }

    @RequestMapping("/create")
    public String create() {

        return "client/create";
    }

    @RequestMapping("/edit")
    public String edit() {

        return "client/edit";
    }

    @RequestMapping("/getbyid")
    @ResponseBody
    public Client getById(int id) {

        return this.clientService.getById(id);
    }

    @RequestMapping("/getall")
    @ResponseBody
    public List<Client> getAll() {

        return this.clientService.getAll();
    }

    @RequestMapping("/save")
    @ResponseBody
    public void save(@RequestBody Client item) {

        this.clientService.save(item);
    }

    @RequestMapping("/update")
    @ResponseBody
    public void update(@RequestBody Client item) {

        this.clientService.update(item);
    }
}

The first three methods: list(), create(), edit() - just return HTML view name. The others methods are more complicated, they represent REST service, exposed to javascript.

Now, we have almost everything we need. The MVC controller will give us HTML and javascript, which will interact asynchronously with the API controller and fetch data from database. AngularJS will help us to display the fetched data as beautiful HTML. We are not going to talk about HTML and javascript in this article. I assume that you are familiar with AngularJS (or KnockoutJS), though it is not that important in this article. The only thing you must know is - every page is loaded as static HTML and javascript, after being loaded it interacts with controller to load all the needed data pieces from database through JSON, asynchronously. And AngularJS helps to display the JSON as beautiful HTML.

Problems

Now, let's talk about problems, that we face in the current implementation.

Problem 1. The first problem is serialization. Data, returned from the controller is serialized to JSON. You can see it in these two controller methods.

@Controller
@RequestMapping({"/client"})
public class ClientController {
 ....
    @RequestMapping("/getbyid")
    @ResponseBody
    public Client getById(int id) {

        return this.clientService.getById(id);
    }

    @RequestMapping("/getall")
    @ResponseBody
    public List<Client> getAll() {

        return this.clientService.getAll();
    }

The Client class is a domain class, and it is wrapped with Hibernate wrapper. So, serializing it can result in circular dependency and will cause StackOverflowException. But there are other minor concerns. For example, sometimes, I need only id and name fields to be present in JSON, sometimes I need all the fields (same objects must be serialized differently - including different sets of fields). The current implementation does not allow me to make that decision, it will always serialize all fields.

Problem 2. If you take a look at the ClientService class, method save(), you will see that there is some code missing.

@Override
@Transactional
public void save(Client item) {

    /* TODO: assign back-references of the child Login objects -
       for each Login: item.Login[i].Client = item; */
    this.clientDao.save(item);
}

Which means, that before saving the Client object, you have to set up back-references of the children Login objects. Every Login class has a field - Client, which is actually a back-reference to the parent Client object. So, in order to save Client with Logins together using cascading save, you have to set up those fields to the actual parent instance. When Client is deserialized from JSON, it does not have back-references. It is a well-known problem among Hibernate users.

Problem 3. If you take a look at the ClientService class, method update(), you will see, that there is some code missing too.

@Override
@Transactional
public void update(Client item) {

    Client existing = this.clientDao.load(item.getId());
    /* TODO: copy changes from item to existing (recursively) */
    this.clientDao.merge(existing);
}

I also have to implement logic, which copies the fields from the deserialized Client object to the existing persistent instance of the same Client. My code must be smart enough to go through the children Logins. It must match the existing logins with the deserialized ones, and copy fields respectively. It must also append newly added Logins, and delete missing ones. After these modifications, the Merge() method will persist all the changes to database. So this is quite sophisticated logic.

In the next section, we will solve these three problems using Upida.

Solution

Problem 1 - Smart Serialization

Let's see how Upida can help us to solve the first problem. The ClientController has two methods that return Client objects - getAll() and getById(). The getAll() method returns list of Clients, which is displayed as grid. I don't need all the fields of the Client object to be present in JSON. The GetById() method is used on the "Edit Client" page. Therefore full Client information is required here.

In order to solve this problem, I have to go through each property of the returned objects, and assign null value to every property that I don't need. This seems pretty hard work, because I have to do it in every method differently. Upida provides us with org.upida.Mapper class which can do it for us. Let's modify the business layer using the Mapper class.

@Service
public class ClientService extends IClientService {

    private IMapper mapper;
    private IClientDao clientDao;

    @Autowired
    public ClientService(IMapper mapper, ClientDao clientDao) {

        this.mapper = mapper;
        this.clientDao = clientDao;
    }

    @Override
    public Client getById(int clientId) {

        Client item = this.clientDao.getById(clientId);
        return this.mapper.filter(item, Leves.DEEP);
    }

    @Override
    public List<Client> getAll() {

        List<Client> items = this.clientDao.getAll();
        return this.mapper.filterList(items, Levels.GRID);
    }
 .....

It looks very simple, Mapper takes the target object or list of objects and produces a copy of them, but every unneeded property is set null. The second parameter is a numeric value which represents the level of serialization. Upida comes with default levels, but you are free to define your own.

public class Levels {

    public static final byte ID = 10;
    public static final byte LOOKUP = 20;
    public static final byte GRID = 30;
    public static final byte DEEP = 40;
    public static final byte FULL = 50;
    public static final byte NEVER = Byte.MAX_VALUE;
}

The last step is to decorate every property of my domain classes with corresponding level. I am going to use DtoAttribute from Upida to decorate the Client and Login class properties.

public class Client extends Dtobase {

    /* fields go here */

    @Dto(Levels.ID)
    public Integer getId()           { return this.id; }
 
    @Dto(Levels.LOOKUP)
    public String getName()          { return this.name; }
 
    @Dto(Levels.GRID)
    public String getLastname()      { return this.lastname; }
 
    @Dto(Levels.GRID)
    public Integer getAge()          { return this.age; }
 
    @Dto(Levels.GRID, Levels.LOOKUP)
    public ISet<Login> getLogins()   { return this.logins; }
}

public class Login extends Dtobase {

    /* fields go here */

    @Dto(Levels.ID)
    public Integer getId()           { return this.id; }
 
    @Dto(Levels.LOOKUP)
    public String getName()          { return this.name; }
 
    @Dto(Levels.GRID)
    public String getPassword()      { return this.password; }
 
    @Dto(Levels.GRID)
    public Boolean getEnabled()      { return this.enabled; }
 
    @Dto(Levels.NEVER)
    public Client getClient()        { return this.client; }
}

After all properties are decorated, I can use Mapper class. For example, if I call Mapper.filter() method with Levels.ID, then only properties marked with ID will be included. If I call Mapper.filter() method with Levels.LOOKUP, than properties marked with ID and LOOKUP will be included, because ID is less than LOOKUP (10 < 20). Take a look at the Client.logins property, as you see there are two levels applied there, what it means ? It means that if you call Mapper.filter() method with Levels.GRID, then logins will be included, but LOOKUP level will be applied to the properties of the Login class. And if you call Mapper.filter() method with level higher than GRID, then the level applied to the Login properties will become respectively higher.

Problem 2 - Back-references

Take a look at the business layer class, save() method. As you see, this method accepts Client object. I use cascading save - I save Client and its Logins together. In order to accomplish this, the children Login objects must have back-reference assigned correctly to the parent Client object. Basically, I have to loop through children Logins and assign Login.client property to the root Client. When this is done, I can save the Client object using Hibernate tools.

Instead of writing a loop, I am going to use org.upida.Mapper class again. Let's modify the ClientService class.

@Service
public class ClientService implements IClientService {

    private IMapper mapper;
    private IClientDao clientDao;

    @Autowired
    public ClientService(IMapper mapper, ClientDao clientDao) {

        this.mapper = mapper;
        this.clientDao = clientDao;
    }
 ....
    @Override
    public void save(Client item) {

        this.mapper.map(item);
        this.clientDao.save(item);
    }

This code will recursively go through properties of the Client object and set up all the back-references. This is actually half of the solution, another half goes in this code. Every child class must implement IChild interface, where it can tell about who his parent is. The connectToParrent() method will be called internally by Mapper class. The Mapper will suggest possible parents based on JSON.

public class Login extends Dtobase implements IChild {

    private Integer id;
    private String name;
    private String password;
    private Boolean enabled;
    private Client client;

    /* getters and setters go here */
 
    public void connectToParent(Object parent) {

        if(parent instanceof Client) {
            this.Client = (Client)parent;
        }
    }
}

If IChild interface is implemented correctly, you only have to call Map() method from your business layer, and all back-references will be assigned correctly.

Problem 3 - Mapping Updates

The third problem is the most complicated, because updating client is a complicated process. In my case, I have to update client fields as well as update children logins' fields, and at the same time I have to append, delete children logins if user has deleted or inserted new logins. By the way, updating any object, even if you are not using cascading updates, is complicated. Mostly, because when you want to update an object, you always have to write custom code to copy changes from incoming object to existing one. Usually the incoming object contains just several important fields to update, the rest are nulls, and therefore you cannot rely on blind copy of all the fields, as you don't want nulls to be copied to existing data.

The Mapper class can copy changes from the incoming object to the persistent one, without overwriting any important fields. How does it work? Upida comes with a UpidaJsonConverter class, which derives from the MappingJacksonHttpMessageConverter used in Spring Mvc by default. UpidaJsonConverter contains some minor adjustments. As you know, every domain class derives from org.upida.Dtobase abstract class. This class contains HashSet of property names. When UpidaJsonConverter parses JSON, it passes the information about parsed fields to Dtobase, and Dtobase object remembers which of the fields are assigned. Therefore, every domain object knows which of the fields are assigned during JSON parsing. Later, Mapper class goes through only assigned properties of the incoming deserialized object and copies their values to the existing persistent object.

Here is the business layer update() method using the Mapper class:

@Service
public class ClientService {

    private IMapper mapper;
    private IClientDao clientDao;

    @Autowired
    public ClientService(IMapper mapper, ClientDao clientDao) {

        this.mapper = mapper;
        this.clientDao = clientDao;
    }
 ....
    @Override
    public void update(Client item) {

        Client existing = this.clientDao.load(item.getId());
        this.mapper.mapTo(item, existing, Client.class);
        this.clientDao.merge(existing);
    }
}

And here is part of the spring beans file. You can see how to set up UpidaJsonConverter to be default converter in your web application. Please, don't worry about switching from Spring default converter. If you take a look at Upida converter, it derives from Jackson converter and provides just minor changes.

<mvc:annotation-driven>
    <mvc:message-converters>
        <bean class="org.upida.spring.UpidaJsonConverter" />
   </mvc:message-converters>
</mvc:annotation-driven>

Notes

Solving the above-mentioned problems is the biggest side of what Upida can do. However, there is another interesting feature, that can help you in implementing validation routines - both server-side and client-side.

You can find out more detail on how to implement validation using Upida in this article: Validating incoming JSON using Upida.

And also, you can find out how to create Single-Page web Application (SPA) using AngularJS in my next article: AngularJS single-page app and Upida.

References

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

vladimir husnullin
Software Developer
United States United States
No Biography provided

Comments and Discussions

 
-- There are no messages in this forum --
| Advertise | Privacy | Mobile
Web04 | 2.8.140905.1 | Last Updated 3 Mar 2014
Article Copyright 2014 by vladimir husnullin
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid