File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Design and the fly likes Design - how map Request parameters data to domain model Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Design
Bookmark "Design - how map Request parameters data to domain model" Watch "Design - how map Request parameters data to domain model" New topic
Author

Design - how map Request parameters data to domain model

Bruno Marinho
Greenhorn

Joined: Nov 05, 2009
Posts: 4
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.


SCJA, SCJP , SCWCD, OCPBCD,OCPWSD
http://javaclojuregroovy.wordpress.com
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2268
    
    3

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!


Cheers, Bob "John Lennon" Perillo
SCJP, SCWCD, SCJD, SCBCD - Daileon: A Tool for Enabling Domain Annotations
Bruno Marinho
Greenhorn

Joined: Nov 05, 2009
Posts: 4
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

Joined: Dec 28, 2007
Posts: 2268
    
    3

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Design - how map Request parameters data to domain model