Spring Boot, decision to create DTO object separately both for REST and JPA

Question

I guess traditionally, one would for a RESTful web service use one type of DTO objects for POJO/JSON conversion, and a separate DTO object for database entity/POJO conversion?

Spring Boot should be more opinionated and easier to use, but would you still use different DTO object types for JSON and database entity representation, or do you convert entity objects directly to JSON?

Answer 1

Let me share my opinion.

At first, I think your question has nothing to do with spring boot. Spring boot just provides a fancy and lightweight way to start the application and allows to build the app in an easier manner. But still you have your rest controller there and from that point it doesn't differ much for any other type of application.

So what you're actually asking is whether it makes sense to maintain an abstraction of JSON objects and converting them to the Business Logic Entity objects and later on converting them once again to Database objects or its enough to maintain only 2 levels and ditch the Json level.

I think the answer is "it depends".

First of all, In general currently the trend is a simplification. So maybe its enough to maintain only 1 level of objects.

There are a lot of advantages of such an approach:

• Obviously less code to maintain
• Speed of development and testing (POJOs should be checked, converters should be tested and so forth)
• Speed of execution - you don't need to waste the CPU time on conversion. A kind of obvious implication.
• Less obvious: Memory consumption. Lets say you work with a big bulk of data returned by your DAO. Let's say it occupies 10MB of memory (just for the sake of example). Now if you start to convert, to Business Entities, you'll spend yet another 10MB and now if its A JSon objects, well its again 10MB. The point is that all these objects may co-exist in memory simultaneously. Of course GC will probably take care of them if you implemented everything right, but this is a different story.

However there is one drawback of such a simplification.

In one word I would call it a Commitment

There are three Types of APIs in the application.

• The API you're committed to at the level of Web Service - The JSon structure. The chances are that various clients (not necessary using the JVM at all) are running against your Web service and consume the data. So they really expect you to provide a JSon objects of the given structure.

• The API of your business. If your Business logic layer is pretty complicated, you probably have an entire team that develops that logic. So you usually work at the level of APIs between the teams.

• The level of DAO - the same story as Business Logic actually.

So now, what happens if you, say, change that API at one level. Does it mean that all the levels will be broken?

Example

Lets say, we don't maintain "JSon" level. In this case, if we change the API at the level of Business Logic, the JSON will also change automatically. All the rest frameworks will happily convert the object for us, and the chances are that the user will get another data.

Another example

Lets say, your BL layer provides a Person entity that looks like this:

class Person {
      String firstName;
      String lastName;
      List<Language> languages;
   }

   class Language {
     ...
   }

Now, let's say you have a UI that consumes your REST service that provides a list of Persons upon request. What if there are 2 different pages in UI. One that shows only the Persons (in this case it doesn't make sense to provide a list of language, spoken by a person). In the second page however you want to get the full information.

So, you'll end up exposing 2 web services or complicating the existing one by some parameters (the more params like this you have, the less it resembles the rest :) ) Maybe separation would help a little here? I don't know.

Bottom line. I would say that as long as you can live without such a separation - do it. It can work even for quite big projects. And of course it can work for small or middle-sized projects.

If you find yourself struggling around fixes and you feel like such a separation would solve the issues - do the separation.

Hope this helps to understand the implications and chose what works for you