0

I am working on spring boot application with CRUD api with input and output as json object. Is it okay to include json->POJO and POJO->json logic in service method? (service method is marked with transactional annotation)

//Controller 
public Map<String, String> getPersonNames(){
    return personSvc.getNames();
}

//Service method
@Transactional(readonly = true)
public Map<String, String> getNames(){
    return populateNames(repo.findAll());
}

private Map<String, String> populateNames(final List<Person> personList) { 
    return ImmutableMap.of(
    //Populate names into map
 );
}

1 Answers1

0

Well, it mostly depends on application you are building.

Based on the information you provided (almost no information) I can only speak in general, but there is a Domain Driven Design (DDD), which is quite common for Spring applications. You can find more info in answers to this question

This kind of design separates your core domain logic from logic that your technological stack forces you to have. Briefly speaking, it keeps domain models (object that you work with) in the depth of your application.

Next, it wraps the core with application layer (where the logic, that relies on domain models, lays). Application layer only knows how to process underlying models.

And the last wrapper is (port) adapter layer. It adapts your logic for specific technology. It can be, for example, external API or wrapper for MongoDB (while application layer declares only an interface for collecting documents, this layer adapts (implements) it for concrete technology). It can also provide a marshalling/demarshalling.


Maybe example can explain it better:

  • Domain model is a document (an article) that your service works with.

  • Application layer knows how to process them (collect, order, filter articles), but knows nothing about JSON serialization.

  • Resource (aka port adapter) knows how to serialize collection of articles into JSON and back, but it's the only thing it does. No logic here


And you may have seen how every layer knows only about it's underlying layers. An article does not know anything, it's just a model. Application knows how to process articles. And adapter knows how to adapt processing results for concrete technology, JSON for instance.

So i would suggest you to provide basic validation (not against domain/application layer logic) and marshalling/demarshalling process at the highest level, at the resource (your @RestController's endpoints, for instance) since JSON is just a way to adapt your domain for external connections

Random Guy
  • 1,095
  • 16
  • 29
  • just to mention, there were no code when i was writing this :) – Random Guy Feb 27 '18 at 21:39
  • @[Random Guy] Would you change anything in above workflow? Also I am trying to avoid lazyinit exception on marshaling and demarshaling, since it requires accessing Model object in Controller which is out of Transaction and can not lazy load properties. Other way was to lazy load it in Service transaction and then return the model object for marshaling. But I thought why iterate over same object property twice. –  Feb 27 '18 at 21:46
  • If I return Person to the controller which is outside of Transaction it throws LazyInitException and to fix that I have to load all related entities of Person which are LazyFetch in service method to make sure LazyInit doesnot occur in Controller. –  Feb 27 '18 at 21:52