We have the following situations in general, consider larger objects than the example.
Situation 1
We can have a request that has all the parameters of the account, {"id":"1";"name":"test","some":"xxx".............} and the other fields.
Situation 2
We can have a request that has some parameters of the account, for example in the case of an update;
{"id":"1";"name":"testUpdated"}
Situation 3
We can have a request that has some parameters of the account, as id plus has others as user together;
{"id":"1";"user":"xxx","service":"yyy"} in that case each piece of request will become an object.
Domain Example
public class Account {
private Long id;
private String name ;
private String some ;
}
I see some options;
1 - I can receive the AccountForm in the controller and set the properties of it in the Account object and others if nescesasrio NO CONTROLLER;
+ atende as situações 1, 2 e 3
+ separa a requisçao do objeto de dominio
- polui o controller com codigo de conversao
- controller fica cheio de setters.. se for uma classe maior como um objeto grande como um pedido fica bem confuso.
controller(AccountForm from){
Account account = new Account()
account.setNome=form.getNome();
account.setSome=form.getSome();
Other outher = new Other();
other.setSome(form.getSome());
}
2 - I can receive in the controller this AccountRequest have a method in it as AccountRequest.getAccount() to return a mapped model, in which case the mapping is in the Request object itself.
+ separa a requisçao do objeto de dominio
+ encapsula a conversao em um lugar de facil acesso.
+ atende situacao1 situacao2 e situacao3;
+ um objeto burro que so tem os parametros da requisçao tem alguma funcionalidade;
- objeto de request tem duas responsabilidades representar a requisiçao e mapear para um model valido.
controller(AccountForm accountRequest){
Account account = accountRequest.getAccount();
Outher outher = accountRequest.getOther();
}
3 - I can receive Direct Account in the controller where it will be filled with nulls.
+ elimino objeto de request
+ alta simplicidade
- atende apenas a situacao1 situacao2 , por que request pode ter informações sobre vários objetos... o que não funcionaria.
- forte acoplamento.
controller(Account account){
account.someMethod();
}
4 - Externalize this mapping of the request parameters to another mapper object by request.
+ isola logica do mapeamento
- complexidade ate para casos mais simples se usado como padrão para tudo por exemplo um find por id.
- mais uma classe para cada request;
In case of APi that has a response it gets even worse 2 classes. speaking in terms of response request ....
request | mapper | model | mapper | response
AccountRequest, AccountRequestMapper,Account,AccountResponseMapper,AccountResponse........
I'm doing tests plus Hibrid of option 3 for simple cases (find by id or updates) .... with option 2 for example for more complex cases ... seems ideal for what I'm seeing, I hope with the opinion of you is clearer .. what could be better, but in the hybrid approach, the problem is that you do not have the famous "STANDARD" and have to think how to do each case, and I see resistance in adopting something like this . The bad thing about STANDARD is that it generates architecture to make a find for example.
What do you use / What would be ideal / What is expressive and easy to maintain?