F�rum Mapeamento dos dados de request para o domain model. #480028

24/05/2014

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.

Jo�o Aquino

Curtir t�pico

+ 0

Responder