I have a small application with classic layers Controller-Service-Dao. Controller actually is REST resource, which deals with JSON data. And the questions are: 1. where is the best place to create business objects from JSON primitives? Controller or Service? Should controller pass primitives from JSON to service methods? 2. If objects should be created in controller layer is it good style to pass in service method primitive value in case it is some kind of search method by id?

UPDATE 1. I'm talking about java:

serviceSearchMethod(int value1, String value2);


SomeObject someObject = new SomeObject(int value1, String value2);

Of course, it can be that someObject contains 10 fields, but controller has only 2 values, so is it good in this case create business object (BO) or it is suitable only in case I can create BO which is not just DTO to service layer, but something valuable from business point of view?

  • 3
    You haven't said much about what your application does, and you're using the word "primitive" like we're supposed to understand what you're talking about. (I know what all the other words mean, but there isn't any one single architecture that is suitable for every possible application, so I think your question needs to be a bit more specific). Feb 28, 2016 at 2:29
  • Which language are you using?
    – Andy
    Feb 28, 2016 at 7:40

2 Answers 2


I prefer to convert the JSON to business objects as soon as possible, and generally this is done in the REST controller class. There are reasons for this:

  • JSON is a data transport format. In a large system there may well be other data transport formats (eg XML or CSV). So if possible your internal representation should be data format independent.
  • Business objects usually have behavioral methods. If the data is still in JSON format, then best of luck with writing behavioral methods :)
  • In most systems, objects are created in code as well as arriving on the wire. It would be weird to have to create a JSON object rather than a Java POJO.

But a caveat - my experience has been with Java REST services. If you are running a server-side Javascript framework, then other considerations may apply.

  • I am running Java system and I'm not talking about parsing JSON objects, sorry that did not mention it clear. I'm talking about passing on service layer integers and strings vs creating a business object and passing it in service.
    – sphinks
    Feb 28, 2016 at 11:03
  • Just make some update to my question.
    – sphinks
    Feb 28, 2016 at 11:11

I work with a lot of such systems (built in PHP, not Java, but it's the same principle) and I agree with @kiwiron: it's better to do it in the Controller layer.

Here are a few of my reasons for recommending it like this:

  • the Controller layer acts as a gateway in-and-out of your system, a communicator with the outside world. Since JSON is the format used to communicate with the outside, the responsibility for encoding/decoding from/to that format should be somewhere in that layer.
  • REST systems (which is what you mentioned you have) use in 99.99% of cases the HTTP protocol for transport. This means you can and it would be nice to negotiate the content to and from the system using the Accept and Content-Type HTTP headers (this is nice because you can easily support multiple formats at the same time). Since your Service and DAO layers should know absolutely nothing about the communication with the outside world, the responsibility of figuring out what the clients/callers provided and asked for (using those HTTP headers) should be in the Controller layer.

There is however a small catch, this could be a common situation in a lot of such systems: What if you have 3 Controllers that rely on the same Service (from the Services layer) ? The best practice described above would be to have the Controllers create the model/entity objects... but if all of them do that, then we would have a not so pretty violation of the DRY principle.

So, this is what I recommend:

  • for each model/entity object, have some sort of Factory or Builder, to transform it from the decoded format (maybe arrays ?) into objects. This way, the transformation is in only 1 place.
  • use those Factories/Builders from the Controller layer
  • make the Service and DAO layers work only with objects.
  • Please, read update 1 in my question. I'm not talking about passing JSON to service. Of course, JSON should be processed by controller.
    – sphinks
    Feb 28, 2016 at 14:03
  • @sphinks oooh now I understand what you meant. In that case, I personally prefer objects, but there are situations where values/primitives make more sense for that particular method signature Feb 28, 2016 at 14:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.