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

controllerservice

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

Best Answer

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.

Related Solutions

Java Design – Controller Calling Multiple Services

In my humble opinion, the controller should be the "facade" itself, that means that the controller should decide which service to call, and the services should be in charge of generating the response object.

What I would do is to define a method per action, and discriminate the service using REST naming, something like this:

@Path("/")
public class MyController {

  @Autowired
  private FirstService firstService;

  @Autowired
  private SecondService secondService;

  @RequestMapping(value = "/service1/{query}", method = {RequestMethod.GET})
  public Response getData(@RequestParam("query") final String query) {

      return firstService.yourMethod(); // inside the service you handle the response.
  }

  @RequestMapping(value = "/service2/{query}", method = {RequestMethod.GET})
  public Response getData(@RequestParam("query") final String query) {

      return secondService.another(); // inside the service you handle the response.
  }

}

Domain-Driven Design – Checking Unique Constraints on Domain Object Attributes Elegantly

Considering domain layer is persistence ignorant and has no idea how to retrieve the data but only how to do operations on them, it cannot really touch the repositories itself.

I would disagree with this part. Especially the last sentence.

While it is true that domain should be persistence ignorant, it does know that there is "Collection of domain entities". And that there are domain rules that concern this collection as a whole. Uniqueness being one of them. And because the implementation of the actual logic heavily depends on specific persistence mode, there must be some kind of abstraction in the domain that specifies need for this logic.

So it is as simple as creating an interface that can query if name already exists, which is then implemented in your data store and called by whoever needs to know if the name is unique.

And I would like to stress out that repositories are DOMAIN services. They are abstractions around persistence. It is the implementation of repository which should be separate from the domain. There is absolutely nothing wrong with domain entity calling a domain service. There is nothing wrong with one entity being able to use repository to retrieve another entity or retrieve some specific information, that cannot be readily kept in memory. This is a reason why Repository is key concept in Evans' book.

Best Answer

Related Solutions

Java Design – Controller Calling Multiple Services

Domain-Driven Design – Checking Unique Constraints on Domain Object Attributes Elegantly

Related Topic