Pessoal,
Em um sistema que tem como foco disponibilizar webservices para que se tenha independência de front end’s (uma visão web, outra android, outra iOS, etc) é recomendado usar TO’s ou usar mesmo as entidades de negócio (pojos “persistentes”)?
Usando TO ganhamos a independência de alterar nossas entidades sem a preocupação de quebrar o contrato com os “clientes”, mas por outro lado temos que ter uma “camada” para fazer a conversão de TO x Entidade e vice versa.
Qual a opinião de vocês?
[quote=leojribeiro]Pessoal,
Em um sistema que tem como foco disponibilizar webservices para que se tenha independência de front end’s (uma visão web, outra android, outra iOS, etc) é recomendado usar TO’s ou usar mesmo as entidades de negócio (pojos “persistentes”)?
Usando TO ganhamos a independência de alterar nossas entidades sem a preocupação de quebrar o contrato com os “clientes”, mas por outro lado temos que ter uma “camada” para fazer a conversão de TO x Entidade e vice versa.
Qual a opinião de vocês?[/quote]
Criar TO (Transfer Object). É para isso que eles servem.
Mas não cometa o erro de fazer 1 para 1 com as suas entidades persistentes e chamar de EntitdadeXYZTO. Não.
Crie uma pacote à parte junto da interface do serviço ( se possível) e crie as classes lá. Você pode agregar informação de mais do que uma entidade no TO se for necessário. Trate o TO como um objeto da view ( porque é isso que ele realmente é)
Faça os seus webservices serem façades do seu domínio. Assim vc não expõe nem os serviços nem as entidades do seus domínio.
Sérgio,
Obrigado pela resposta. Era isso que estava pensando mesmo.
E no caso o cliente vai enviar o TO que será recebido pelo webservice e repassado ao domínio que fará os tratamentos necessários:
correto?
[quote=leojribeiro]Sérgio,
Obrigado pela resposta. Era isso que estava pensando mesmo.
E no caso o cliente vai enviar o TO que será recebido pelo webservice e repassado ao domínio que fará os tratamentos necessários:
correto?[/quote]
O webservice é um serviço e a primeira coisa que um serviço faz é validar o seu input conforme o seu contrato. Portanto, a validação vem primeiro. Validando os TO mesmo. Depois a conversão. Depois a validação das entidades ( se necessário), finalmente o processo chamando outros serviços ou outros objetos do domínio.
Certo, obrigado cara
Bom, eu já discordo…
Acredito que existem poucas coisas que são, de fato, dependentes de TO. Há muito que pode ser feito usando adapters JAXB e outros mecanismos presentes na API que tornam TO’s desnecessários.
Você poderia listar algum exemplo, para que eu possa expôr melhor meu argumento?
[]'s
Alexandre,
No caso você optaria por trafegar xml?
É que e o meu receio é caso eu precise alterar a minha classe de domínio de alguma maneira eu acabar quebrando os clientes do serviço.
Não usei o JAXB, mas vou considerar a sua sugestão. Ainda estou no início e não fechei em definitivo o que de fato vamos usar.
Se você puder expor alguns motivos que o levariam a optar por não usar TO e sim o JAXB seria de grande valor para mim.
Att
[quote=leojribeiro]Alexandre,
No caso você optaria por trafegar xml?
É que e o meu receio é caso eu precise alterar a minha classe de domínio de alguma maneira eu acabar quebrando os clientes do serviço.
Não usei o JAXB, mas vou considerar a sua sugestão. Ainda estou no início e não fechei em definitivo o que de fato vamos usar.
Se você puder expor alguns motivos que o levariam a optar por não usar TO e sim o JAXB seria de grande valor para mim.
Att[/quote]
Eu sempre adoto o NÃO uso de TO’s como regra, e o contrário como exceção. Note o seguinte: usar ou não TO está em pauta, web services (pelo menos os clássicos), não. Se você usar web services clássicos em Java, é obrigatório utilizar o JAXB.
Posto isso, saiba que existem várias maneiras de adaptar o seu XML. Existem:
Assim, eu não vejo motivos para utilizar TO porque a maioria do que precisa ser feito, hoje, que justificaria um TO, pode ser perfeitamente adaptado utilizando estes e outros mecanismos (inclusive validação, que pode ser atendida pela JSR 303).
[]'s
[quote=Alexandre Saudate][quote=leojribeiro]Alexandre,
No caso você optaria por trafegar xml?
É que e o meu receio é caso eu precise alterar a minha classe de domínio de alguma maneira eu acabar quebrando os clientes do serviço.
Não usei o JAXB, mas vou considerar a sua sugestão. Ainda estou no início e não fechei em definitivo o que de fato vamos usar.
Se você puder expor alguns motivos que o levariam a optar por não usar TO e sim o JAXB seria de grande valor para mim.
Att[/quote]
Eu sempre adoto o NÃO uso de TO’s como regra, e o contrário como exceção. Note o seguinte: usar ou não TO está em pauta, web services (pelo menos os clássicos), não. Se você usar web services clássicos em Java, é obrigatório utilizar o JAXB.
Posto isso, saiba que existem várias maneiras de adaptar o seu XML. Existem:
Assim, eu não vejo motivos para utilizar TO porque a maioria do que precisa ser feito, hoje, que justificaria um TO, pode ser perfeitamente adaptado utilizando estes e outros mecanismos (inclusive validação, que pode ser atendida pela JSR 303).
[]'s[/quote]
ahum… e onde vão essas anotações ? nos objetos de dominio ? Porque é que anotações de visão estão no domínio ?
O fato de vc poder fazer isso, ão significa que é a forma mais fácil de manter. Porque quando vc precisa de agregar informações de várias entidades , não tem como. Este é o problema. Vc está acoplando a transformação xml às entidades do dominio. Acoplar nunca é bom.
Os adapters e os factories eu não entendi exactamene o que estariam adaptando e/ou criando, mas suponho que objetos. Que tipo de objetos ? De entidade ? HashMaps ? o quê ?
[quote=sergiotaborda]
ahum… e onde vão essas anotações ? nos objetos de dominio ? Porque é que anotações de visão estão no domínio ?
O fato de vc poder fazer isso, ão significa que é a forma mais fácil de manter. Porque quando vc precisa de agregar informações de várias entidades , não tem como. Este é o problema. Vc está acoplando a transformação xml às entidades do dominio. Acoplar nunca é bom.
Os adapters e os factories eu não entendi exactamene o que estariam adaptando e/ou criando, mas suponho que objetos. Que tipo de objetos ? De entidade ? HashMaps ? o quê ?[/quote]
Concordo até certo ponto com você. Você tem razão, acoplar view não é bom, porém entendo que este é um caso especial de view, posto que este controle é feito por anotações que estão presentes na própria JDK. Além disso, qualquer modificação sobre estes padrões pode ser feito utilizando os já citados adapters, cujo controle é feito principalmente pela anotação @XmlAdapter (http://jaxb.java.net/nonav/2.2.4/docs/api/javax/xml/bind/annotation/adapters/XmlAdapter.html).
Considero que, neste caso (não em todo caso model -> view) a manutenção seja facilitada pelo controle diretamente na entidade, já que dificilmente este controle precisará ser feito de maneira diferenciada entre vários web services, ou qualquer outro caso que exija diferenciação entre as apresentações das entidades.
[]'s
O que queremos fazer é um backend independente de qualquer frontend que seja desenvolvido (JSF, Flex, Android, iOS, etc)…
Por isso que inicialmente nos veio a idéia do TO, para que quando eu precisar alterar alguma coisa nas classes de domínio isso não impacte no contrato de comunicação do backend com os frontends.
Então, o que precisamos é uma view independente da implementação do backend.
Agora a opinião do Alexandre fez surgir algumas interrogações aqui (no bom sentido).
A conversa está boa, esta sendo enriquecedora.
Ah um outro ponto é que sim, a princípio vamos usar Webservices para a integração do backend com os frontends
Estes web services serão clássicos ou Restful ? Se forem Restful, você vai usar XML ou JSON?
[]'s
Alexandre, a princípio clássicos, mas estaremos analisando o Restful.
A equipe não domina 100% webservices, pelo menos ainda, mas como precisamos criar o backend da forma que descrevi no post anterior, acreditamos ser a solução ideal.
A propósito estou lendo o SOA Aplicado. Ainda estou no início, mas acredito que será de grande ajuda. Parabéns pelo livro
[quote=leojribeiro]Alexandre, a princípio clássicos, mas estaremos analisando o Restful.
A equipe não domina 100% webservices, pelo menos ainda, mas como precisamos criar o backend da forma que descrevi no post anterior, acreditamos ser a solução ideal.
A propósito estou lendo o SOA Aplicado. Ainda estou no início, mas acredito que será de grande ajuda. Parabéns pelo livro[/quote]
Opa, obrigado!
A propósito, o livro tem um capítulo específico que fala destes adapters (e outras coisas). É o capítulo 3. Na verdade, inclusive mencionei neste capítulo este cenário, ou seja, como manter mapeadas classes de negócio e usar JAXB nelas.
[]'s
Achei esse topico exatamente quando ia abrir um com um assunto parecido, senão o mesmo. Vamos a algumas dúvidas:
1 - A questão é quando já possuo um serviço/classe de negócio na minha aplicação já pronto
como fica para expor ele como um web service, uma vez que os serviços estão construidos sobre o modelo/entidades do sistema
e geralmente as informações que precisam ser expostas estão espalhadas em varias entidades, apesar dessas entidades estarem
ligadas, ou seja, da para recuperar a informação a partir da entidade principal porem precisaria ser enviados muitos dados na resposta
do web service. Nesse ponto acredito que é ponto para os TOs.
2 - Para não enviar toda a estrutura de entidades que dependem umas das outras criamos os TOs, porem como o serviço seria reaproveitado
uma vez que ele já está implementado sobre as entidades? Teria um método novo para poder retornar os TOs? Sendo assim, sempre ou quase
sempre que uma funcionalidade precise ser exposta como web service teria que ser em un método a parte para poder converter as entidades
em TOs e retornar os TOs.
3 - Muitas das funcionalidades de negócio recebem uma ou mais entidades como parametros, o que pra web services tambem daria problema
tanto por ser entidade do sistema e não um TO quanto por, se não me engano é uma boa pratica ter os parâmetros de entrada dos web services
como tipos simples.
No geral a dúvida se baseia em não aproveitar os métodos já prontos, pois eles não estão contrstruidos sobre os TOs.
[quote=rafaelmeireles]Achei esse topico exatamente quando ia abrir um com um assunto parecido, senão o mesmo. Vamos a algumas dúvidas:
1 - A questão é quando já possuo um serviço/classe de negócio na minha aplicação já pronto
como fica para expor ele como um web service, uma vez que os serviços estão construidos sobre o modelo/entidades do sistema
e geralmente as informações que precisam ser expostas estão espalhadas em varias entidades, apesar dessas entidades estarem
ligadas, ou seja, da para recuperar a informação a partir da entidade principal porem precisaria ser enviados muitos dados na resposta
do web service. Nesse ponto acredito que é ponto para os TOs.
[/quote]
Juro que não entendí o problema aqui. OK, você tem a informação espalhada em várias entidades… e ?
Uma boa especificação de web services segue as boas práticas de SOA, que visa ter um modelo canônico, com cada entidade bem delimitada. Dessa forma, faz mais sentido você ter mesmo a informação espalhada em várias entidades do que ter TO’s para colocar tudo num lugar só.
Pois é, essa idéia de ter um TO já está se tornando uma confusão tão grande que fica até difícil seguir com uma linha de raciocínio.
Em SOA, nós desenvolvemos as entidades canônicas, orientados pelo negócio. Essas entidades são reaproveitáveis justamente por seguirem o negócio e não a implementação. Se as entidades da aplicação são feitas de acordo com esse modelo canônico, bem. Se não, poderia checar se é possível alterá-las. Somente em caso de “não, não é possível alterá-las” seria o caso de criar TO’s.
Veja bem, as boas práticas de desenvolvimento de serviços pregam que, sendo o contrato (WSDL) feito para o cliente e não para a implementação, deve-se ignorar tanto quanto possível a forma como ele vai ser implementado. Isso porque a linguagem em que o serviço é implementado hoje pode não ser a mesma de amanhã, e para ter esse reuso é necessário desacoplar-se ao máximo da implementação.
Posto isso, um TO talvez seja uma boa idéia somente nesse sentido, em que a aplicação que está sendo exposta como serviço já está implementada e não é possível alterar as entidades que já existem e estas não são compatíveis com o modelo canônico.
Note que, idealmente, o TO aqui deveria ser mais desenvolvido considerando as Entities e Value Objects do DDD (que se comunicam com Adapters - também do DDD) do que o TO tradicional dos antigos padrões J2EE.
[quote=rafaelmeireles]
3 - Muitas das funcionalidades de negócio recebem uma ou mais entidades como parametros, o que pra web services tambem daria problema
tanto por ser entidade do sistema e não um TO quanto por, se não me engano é uma boa pratica ter os parâmetros de entrada dos web services
como tipos simples.
No geral a dúvida se baseia em não aproveitar os métodos já prontos, pois eles não estão contrstruidos sobre os TOs.[/quote]
Na verdade, é exatamente o contrário. Assim como em OO, é péssima prática de web services ter operações que recebem tipos simples como parâmetro. Na verdade, o ideal é sempre ter entidades canônicas para receber como entrada das operações. Conhece aquela máxima de OO? O que é melhor:
public void criarCliente (String nome, String sobrenome, Date dataNascimento)Ou
public void criarCliente (Cliente cliente) ?
Pois é, passar o cliente como parâmetro é sempre mais flexível. Web services seguem esta mesma regra.
[]'s