• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Design - how map Request parameters data to domain model

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is a design question is the same problem in any language.

Guys as you do to map the controller to the domain model?

We have situations in general larger than ... consider the example objects .

situation.1 - We have a request that has all the parameters of the account ;
{ " id" : " 1 " , "name " : "test " , "some " : " xxx " } ............. and other fields .

situation.2 - can request that has to have a certain account parameters , for example in the case of an update;
{" id" , " 1" , "name " , " testUpdated "}

situation.3 - We have a request that has some parameters of the account , others have more like id as user together;
{ " id" : " 1 " , "user " : " xxx " , "service " : " yyy " } in which case each piece of the request will turn an object .



I see a few options ;

1 - Can I get AccountForm in the controller and set the properties for the Account object and others in CONTROLLER ;

+ ok for situation.1 situations 2, and situation.3
+ Separates the requisition of the object domain
- Pollutes the controller with code conversion
- Controller is full of setters .. if a higher class as a large object as a request is very confusing .



2 - Can I get AccountRequest in the controller and have a method in itself as AccountRequest.getAccount ( ) to return a mapped model , in this case the mapping is at own Request object .

+ Separates the requisition of the object domain
+ Encapsulates the conversion in a place with easy access .
+ Meets situation.1 situation.2 and situation3 ;
- Request object has two responsibilities represent the request and map to a valid model .


3 - Can I get the controller Direct Account which had been filled with nulls .

+ Eliminate object request
- Serves only situation.1 situation.2 .



4 - Outsource this mapping request parameters to another object mapper for request ..

+ Isolates logic mapping
- Until complexity for simpler cases are used as standard for all such a find by id .
- One more class for each request ;

In the case of API gets worse response has two further classes. speaking in terms of request for response .... AccountRequest, AccountRequestMapper, Account, AccountResponseMapper, AccountResponse ........

I'm doing more testing the Hybrid option 3 for simple cases (find ID or updates) .... with option 2 for example for more complex cases ...

What would be ideal / What is expressive and easy to maintain? Thank you.
 
Bartender
Posts: 2292
3
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Greetings, "Diabo Loiro"!

Well, I'd say it depends on the functionality you're trying to invoke, but the most important thing to remember is that a controller just receives a request, delegates the handling of it to another object and returns to the client the proper view. If the object of your domain model already exists in the database, you can send to the controller only its id and send it to the application layer. For example, let's assume your controller is an HttpServlet object:



Your AccountFacade could be like this:



If you have to pass all parameters to the controller (e.g. when you have to create an account), you can rely on another object in the presentation layer to create the object to you, get it, and then send it to your application layer.



Then your controller can use it to build Account objects.

Now, one last thing I'd like to ask you. Here at the ranch, we don't have many rules, but one we have to follow regards the users' display name. I'd like to ask you to change your current display name to your real name. You can do so by clicking here. Thanks!
 
Bruno Marinho
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thanks, but the question is more about where i can tranform request data to domain object (ddd) .. i can receive the entity from controller with spring or i create mappers class to do this, or i can create one form object?

about your response, i dont use "aplication services" i only use "domain service" that orchestrate the logic than i cant put in one entity or value object
 
Roberto Perillo
Bartender
Posts: 2292
3
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Bruno Marinho wrote:thanks, but the question is more about where i can tranform request data to domain object (ddd) .. i can receive the entity from controller with spring or i create mappers class to do this, or i can create one form object?



Well, as I said, it depends. If the functionality involves objects that already exist in the database, you can just send an id from the presentation layer to the application layer and it will be retrieved there. If the functionality involves creating new objects (e.g. when you create new entries in a database), then you can ease things and create them in the presentation layer, and send to your application layer the objects already populated.

Bruno Marinho wrote:i dont use "aplication services" i only use "domain service" that orchestrate the logic than i cant put in one entity or value object



These are two different things. The Application Services is a pattern that allows you to keep your controller thin and also allows you to keep specific logics away from your domain/business objects.
 
reply
    Bookmark Topic Watch Topic
  • New Topic