Temos as situações em geral… considere objetos maiores que o exemplo.
[color=red]situacao1[/color] - Podemos ter uma request que tem todos os parâmetros do account;
{“id”:“1”;“name”:“test”,“some”:“xxx”…} e os outros campos.
[color=red]situacao2[/color] - Podemos ter uma request que tem alguns parâmetros do account, por exemplo no caso de um update;
{“id”:“1”;“name”:“testUpdated”}
[color=red]situacao3[/color] - Podemos ter uma request que tem alguns parâmetros do account, como id mais tem outros como usuário junto;
{“id”:“1”;“user”:“xxx”,“service”:“yyy”} nesse caso cada pedaço da request vai virar um objeto.
Exemplo de Dominio
public class Account {
private Long id;
private String name;
private String some;
private String other;
private String xxxx;
//more fields
}Vejo algumas opções;
1 - Posso receber no controller esse AccountForm e setar as propriedades dele no objeto Account e outros se nescesasrio NO CONTROLLER;
[color=blue] + atende as situações situacao1,situacao2 e situacao3
- separa a requisçao do objeto de dominio[/color]
[color=red]- 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.[/color]
controller(AccountForm from){
Account account = new Account()
account.setNome=form.getNome();
account.setSome=form.getSome();
Other outher = new Other();
other.setSome(form.getSome());
}
2 - Posso receber no controller esse AccountRequest ter um metodo nele mesmo como AccountRequest.getAccount() para devolver um model mapeado, nesse caso o mapeamento fica no proprio objeto de Request.
[color=blue]+ 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;[/color]
[color=red] - objeto de request tem duas responsabilidades representar a requisiçao e mapear para um model valido.[/color]
controller(AccountForm accountRequest){
Account account = accountRequest.getAccount();
Outher outher = accountRequest.getOther();
}
3 - Posso receber Account direto no controller onde ficara cheia de nulos.
[color=blue]+ elimino objeto de request[/color]
[color=blue]+ alta simplicidade [/color]
[color=red]- atende apenas a situacao1 situacao2 , por que request pode ter informações sobre vários objetos… o que não funcionaria.[/color]
[color=red] - forte acoplamento.[/color]
controller(Account account){
account.someMethod();
}
4 - Externalizar esse mapeamento dos parametros da requisição para outro objeto mapeador por request…
[color=blue]+ isola logica do mapeamento[/color]
[color=red]- 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;[/color]
No caso de APi que tenha resposta fica pior ainda mais 2 classes.
falando em termos de request de response…request | mapper | model | mapper | response
AccountRequest, AccountRequestMapper,Account,AccountResponseMapper,AccountResponse…
Estou fazendo testes mais o Hibrido da opção 3 para casos simples(find por id ou updates)… com a opção 2 por exemplo para casos mais complexos… parece o ideal pelo que estou vendo, espero que com a opiniao de voces fique mais claro… o que poderia ser melhor, porém na abordagem hibrida, o problema é que voce não tem o famoso “PADRAO” e tem que pensar em como fazer a cada caso,e vejo resistência em adotar algo assim.
O ruim do PADRAO é que gera arquitetura mostro para fazer um find por exemplo.
O que vocês usão /O que seria ideal/ O que fica expressivo e de facil manutençao?
Obrigado.