Retorno de Consultas DAO

*** aplausos pro louds ***

Rodrigo, sobre a sua duvida de como fazer os objetos do dominio falarem com o DAO e serem vistos pela UI ao mesmo tempo, dah uma lida na thread do Rafael Steil sobre o refactoring do JForum. Eh exatamente o que ele ta fazendo

This message was edited 2 times. Last update was at 16/04/2005 01:49:01

Eu li o tópico que vc falou... Ufa... Deu trabalho:
http://www.guj.com.br/posts/list/22689.java

Seguem as seguintes considerações:

1) Existe a regra de ouro da refatoração:
Mantenha isto simples. Faça a solução mais simples que resolva o problema de hoje. Caso você repita isto uma vez, preste atenção mas ainda não mude nada. Se acontecer denovo, refatore.
_ é tão legal esta regra!!! Poupa um tempo evitando que gastemos horas com a solução mais flexível, ótima e elegante para besteiras sem repetição.
_ corolário: você pode fazer copy & paste de uma parte do código uma única vez, mas pode.

2) SmallTalk existe sem Interfaces. Mas, Interface é apenas a implementação Java (e de outras linguagens) do padrão Strategy o qual existe em SmallTalk. No entanto, você tinha absoluta razão naquela discussão, devido a regra de ouro da Refatoração.

3) Finalmente o ponto sobre DTO. O que impede que eu extrai uma interface de um objeto que seja apenas uma visão parcial de seu estado?

Objetos em banco de dados podem conter um quantidade de informações que (para um ser contexto) seja irrelevante. Poderia tratar apenas parte dessas informações?

E outra: eu gostaria de fornecer a uma classe cliente informações sobre uma certa área de negócio. Poderia expor apenas os valores do objeto sem expor as regras de negócio , ou métodos que não me interessa que o cliente enxergue ?

Note, eu não estou falando em criar objetos com apenas getters e setters. Estou falando de expor uma interface de um pojo que contenha apenas os tais getters e setters. (em última instância um cliente "safado" poderia acessar os demias métodos do objeto por reflection ou por casting. Haveria alguma maneira de evitar isto?)

Valeu.

Expor uma interface mais limitada a objetos para clientes que nao deveriam acessar metodos "perigosos" nao tem problema algum. Eh uma boa ideia, alias, se vc nao souber quem esta do outro lado. Do contrario, nao vejo muito sentido - se o dominio so vai ter clientes que vc mesmo vai desenvolver, pula essa parte e documenta em algum lugar "este metodo nao deve ser chamado fora da camada tal"

This message was edited 1 time. Last update was at 16/04/2005 10:29:36

+4 pontos pela qualidade da resposta.
+1 pela velocidade...

cv wrote:
Do contrario, nao vejo muito sentido - se o dominio so vai ter clientes que vc mesmo vai desenvolver, pula essa parte e documenta em algum lugar "este metodo nao deve ser chamado fora da camada tal

Eu vejo um sentido. Para mim fica mais fácil... sem ter que consultar API sei (pelo código) o que pode ou não pode ser usado. E acho mais! Acho que isto ajuda num trabalho de equipe pois fica bem claro no "Ctrl + Espaço" o que pode ser usado.

Tipo uma programação defensiva:
http://c2.com/cgi/wiki?DefensiveProgramming

Pelo que o pessoal falou o serializeble do objeto é igual ao seu equivalente em DTO, uma vez que só o estado precisa ser "serializado". É isto mesmo ?

Notícias, artigos e o maior fórum brasileiro sobre Java