olá pessoal, eu estava relendo as edicoes da MundoJava numeros 15 e 17 onde o Shoes fala de arquitetura de aplicações JavaEE e em seguida li vários tópicos aqui no forum sobre o assunto, e isso me fez pensar um pouco, e gostaria da opinião de voces.
No princípio, em sempre pensava em tudo OO, como “tem que ser”… mas as “boas práticas” que eram sopradas daqui e dali de outras pessoas acabaram me levando a criar arquiteturas totalmente procedurais, no estilo AnemicDomainModel, onde eu tenho os tao “adorados” DTOs e as classes BO que fazem as operações em cima do DTO. Todas as minhas classes de negócio recebem como argumento um DTO e aí é só trabalhar com o objeto como se fosse um objeto normal, com dados e operações.
Conforme eu fui usando assim, me acostumei de um tanto, que agora to precisando da ajuda de voces pra descauterizar minha mente.
Usando esse modelo com o objeto quebrado em dois, eu “ganho” em manter meus objetos “imutáveis” nas camadas da minha app onde nao deveriam ter operações de negócio, como na minha view. Dessa forma, na view/controler eu crio meus DTOs e passo eles como parametros para os Facades e na implementacao do meu “subsistema” eu instancio as classes de negócio passando os DTOs como parametro e faço tudo lá dentro. Inclusive posso colocar os contrutores dessas classes como protected para evitar que fiquem sendo instanciadas em qualquer lugar da minha aplicação.
Estando acostumado a fazer desse jeito, eu acho estranho buscar do banco (com as minhas DAOs) e retornar objetos inteligentes que podem ter seus métodos de negócio invocados em qualquer parte da app. O mais engraçado é eu achar estranho usar objetos com dados e operaçoes sendo que é pra isso que um objeto serve hehehe.
Aliado a isso, tem os casos onde os clientes podem de uma hora pra outra optarem por uma arquitetura distribuída, onde aí sim os DTOs poderiam fazer sentido. Ou ainda o mesmo sistema ser vendido para diversos clientes, onde cada um pode ter uma demanda diferente e consequentemente cada uns podem adotar uma arquitetura distribuída.
Concordo plenamente com a observaçao que quase todas applicacoes JavaEE que eu vejo nao sao distribuídas (eu particularmente nao participei do desenvolvimento de nenhum), mas como fica nesse caso onde a aplicação vira um software de prateleira? E a questao de poder invocar lógica em qualquer lugar da aplicação, já que os objetos que antes eram “burros” agora ficaram “inteligentes”?
Olá,
Sobre DTOs:
Eu tenho certeza que os DTOs que você produz na sua aplicação não são DTOs de verdade (pelo menos segundo minha experiência como consultor). Por quê? Porque eles não são otimizados apra transferir dados na rede, são apenas estruturas de dados. isto faz com que o uso de DTO hoje não vá te trazer nenhum benefício quando seu sistema virar distribuído, pois seus DTOs não estão prontos para isso.
O que você chama de VO/TO/DTO provavelmente são, na verdade, apenas estruturas de dados. O uso do nome do padrão é apenas para aliviar a consciência.
No caso de um Domain Model de verdade, ao utilizar objetos inteligentes e não DTOs basta que você crie um mecanismo que transforma objetos de negócio em DTOs, este sim DTOs de verdade otimizados para redes. Existe um diagrama que msotra bem como isso é feito, se não me engano está na MJ 15, mas se nãoe stiver lá procure minha palestra sobre camadas no fragmental.com.br .
No caso de ter operações de negócio disponíveis para o cliente:
Se você realmente precisa que seus objetos escondam operações das camadas clientes, utilize interfaces para isso. Na minha experiência isso é raramente necessário, e linguagens dinâmicas totalmente OO como Smalltalk e Ruby nem mesmo oferecem recursos parecidos.
Utilizando uma interface que omite os métodos de negócio, exibindo apenas os métodos que o cliente deve utilizar, você evita o problema de um cliente chamando uma operaçõa imprópria.
obrigado pela resposta Shoes…
com relacao aos DTOs que eu falei, nem era pra aliviar a consciencia nao… na verdade nunca me senti totalmente a vontade com eles… mas com o “desenvolver” da arquitetura, pareceu que assim as coisas ficariam mais separadinhas e tal. Mas eu nunca gostei da idéia de usar struct no Java. Eu usei o nome DTO porque nos demais topicos que li aqui, era o nome mais usado, mas na verdade no dia-a-dia eu chamo mesmo de bean (mas só no sentido de ser uma classe com get/set e construtor default, sem levar em conta o componente da sun etc…).
Mas já que voce falou com que isso nao me daria os benefícios de um DTO de verdade, será que teria como voce me esplicar como eu teria esse DTO? Como falei, nunca trabalhei na pratica com aplicações distribuídas, entao pode parecer uma pergunta meio boba, mas fiquei curioso pelo que voce disse. Pelo que o cv falou em outro tópico, o falo de usar um objeto com métodos nao o torna mais difícil de trafegar pela rede porque na verdade só os dados sao enviados, mas aí eu fiquei na dúvida do porque dos DTOs (ou VOs). Nao sei se entendi mal, mas de qualquer jeito, se poder dar mais uma esplicada…
E pra finalizar (neste post), num exemplo bem simples, caso voce use o hibernate (ou JDO etc), no seu método “findAll” voce retorna todos objetos do modelo da aplicação mesmo né. Com todos os métodos necessários para a lógica ligada a esses objetos. E isso mesmo ou tem mais coisas? valeu.
Esse “de uma hora pra outra” vai demorar mais do que você imagina 
. Uma arquitetura mais distribuída levanta uma série de dificuldades e a necessidade ou não de DTOs é só uma delas.
sabe o que é Rafael? As vezes os clientes são meio criativos, e eu gostaria de ter algo que nao fosse tão impactado caso um cliente desses resolva usar uma arquitetura distribuída. Pessoalmente nao aconteceu comigo AINDA, mas já acontecer ao meu redor hehehe. Tem muitas aplicações por aí rodando em Servidores J2EE sem a menor necessidade só porque o cliente acha que precisa, sendo que a app usa na verdade spring e hibernate :?
Eu sei também que a gente nao pode fazer sempre uma aplicacao pensando na possibilidade de que mude tudo de uma hora pra outra e com isso encontrar motivos para deixa tudo mais complexo do que poderia ser. Prefiro seguir mais o estilo do XP de nao ficar querendo prever o futuro. Eu acho também que nao é tao fácil mudar para algo distribuido onde a aplicação já está rodando, mas quando pensamos em vender a aplicação para outros clientes, acho que a possibilidade de acontecer coisas assim é maior, não é?
Minha preocupação (e a do resto do mundo :lol: ) é encontrar o equilíbrio… e até por isso fiquei na dúvida quando o shoes disse que esses “beans” que eu to usando nao vao servir como DTOs de verdade. Alguem aí poderia me esclarecer um pouco mais?