Should controller layer create model objects or they should be created by service layer?

Question

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);

vs

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

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?

Answer 1

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.

Answer 2

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.