http://www.guj.com.br/posts/list/12.java JForum - http://www.jforum.net
Depois que o cv me instigou a ler mais sobre o assunto, encontrei o seguinte artigo, que deveria ter lido tempos atrás:
http://www.javaworld.com/javaworld/jw-05-2001/jw-0518-encapsulation.html

Nele, entre outras coisas, o autor afirma o seguinte:
[quote]Encapsulation rule 1: Place data and the operations that perform on that data in the same class[/quote]

Sendo assim, DAO não seria uma anti-pattern? Operações CRUD deveriam então ser realizadas dentro das próprias classes? Ou não?

E analisando a evolução do código do autor, percebi o uso de getters e setters pode ser arriscado, então deve-se pensar algumas vezes e escrever o código com cuidado.

Porém, ao usar frameworks como Hibernate, que provê muitas facilidades, o desenvolvedor é obrigado a definir getters/setters para todos os atributos a serem persistidos. E então? Usar ou não usar essas facilidades?

Obrigado pessoal.
]]> http://www.guj.com.br/posts/preList/20668/109156.java http://www.guj.com.br/posts/preList/20668/109156.java GMT
Sobre o DAO, de certa forma eh um anti-pattern do jeito que normalmente se ve feito por ai. Uma alternativa seria o ActiveRecord, do tio Fowler: http://patternshare.org/default.aspx/Home.MF.ActiveRecord

PS: avatar comedia ]]> http://www.guj.com.br/posts/preList/20668/109172.java http://www.guj.com.br/posts/preList/20668/109172.java GMT
Mas cv, sobre o link que você me passou, bem ... como implementar isso de forma coerente?
[code]class Pessoa() implements HibernateSessionAware
{
// ...
public void save()
{
session.save( this );
}
}[/code]
Isso?

E como colocaria várias operações dentro de uma transação fazendo desta maneira? E se o meu domínio tem centenas de objetos, não fica meio complicado para manter essas classes que implementam ActiveRecord?

Obrigado cv :D

ps.: fala pro sr Flower aumentar o tamanho do texto do site dele :mrgreen:]]> http://www.guj.com.br/posts/preList/20668/109178.java http://www.guj.com.br/posts/preList/20668/109178.java GMT
Lipe, que cada vez mais sabe que não sabe nada ]]> http://www.guj.com.br/posts/preList/20668/109211.java http://www.guj.com.br/posts/preList/20668/109211.java GMT
[list][url=http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html] Why getter and setter methods are evil [/url][/list]
[list][url=http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox.html] Building user interfaces for object-oriented systems[/url][/list]

Nesse último ele argumenta que MVC não é OO. Eu acho que ele se apega demais ao encapsulamento. É uma diretriz, não uma lei. De qq forma é uma boa leitura.
]]> http://www.guj.com.br/posts/preList/20668/110382.java http://www.guj.com.br/posts/preList/20668/110382.java GMT Fico imaginando a cena de alguem que acabou de ler o artigo onde eh argumentado que "mvc nao eh OO" e, por tal razao, declara a todos da equipe de desenvolvimento que "..nao vamos mais usar mvc pq ele nao eh oo".

Rafael]]> http://www.guj.com.br/posts/preList/20668/110394.java http://www.guj.com.br/posts/preList/20668/110394.java GMT
O que eu achei interessante é o "absurdo" a que se chega quando se toma uma diretriz como se fosse um axioma absoluto. O projeto de um sistema envolve uma série de de escolhas de engenharia - se privilegia um aspecto em detrimento de outro. Isso talvez seja menos visível em software do que em outras áreas, porque as limitações físicas são muito menos importantes do que, por exemplo, ao se construir uma ponte.

O Holub acha que encapsulamento é uma regra inviolável. Mas, como os milhões de programas escritos usando MVC desde o smalltalk-80 mostram, é possível obter sistemas elegantes e funcionais relaxando um pouco o encapsulamento. ]]> http://www.guj.com.br/posts/preList/20668/110402.java http://www.guj.com.br/posts/preList/20668/110402.java GMT
[code]
class TimerDoSistema {
private Date dataInterna;

public void init() {
this.dataInterna = new Date();
}

public Date getData() {
return this.dataInterna;
}
}
[/code]

digamos que o a intencao era nao permitir que a data interna fosse alterada, e portando nao foi adicionado um setXxx(). O problema eh que, por estar o getData() retornando a referencia para a instancia da classe Date, qualquer metodo podera ser chamado, mudando as prpriedades internas:

[code]
TimerDoSistema t = new TimerDoSistema();
t.init();

// Altera a data
t.getData().setTime(System.currentTimeMillis());
[/code]

A solucao para isso retornar uma copia ao inves da referencia. Porem, fazer isso somente "por fazer" - ou seja, sem a necessidade real de imutabilidade - somente teria resultados mais "desfavoraveis" que a favor.

O problema, porem, eh fazer 90% dos desenvolvedores entender isso.

Rafael]]> http://www.guj.com.br/posts/preList/20668/110404.java http://www.guj.com.br/posts/preList/20668/110404.java GMT A solucao para isso retornar uma copia ao inves da referencia. Porem, fazer isso somente "por fazer" - ou seja, sem a necessidade real de imutabilidade - somente teria resultados mais "desfavoraveis" que a favor.

O problema, porem, eh fazer 90% dos desenvolvedores entender isso.
[/quote]

Sei lá. Eu acho que imutabilidade na verdade deveria ser mais usada. Simplifica bastante o contrato da classe e vc não precisa se preocupar muito com mudança de hash-code. Além de poder dar alguma vantagem minuscula de performance (isso é secundário).

edição: Ficar copiando na hora de entregar para o cliente geralmente quer dizer q a classe do objeto retornado deveria ter sido imutavel. Acho q foi mancada da sun fazer o Date mutável.]]> http://www.guj.com.br/posts/preList/20668/110416.java http://www.guj.com.br/posts/preList/20668/110416.java GMT
Eu acho que encapsulamento não pode ser tudo ou nada, tem que existir uma maior liberdade para outros objetos colaboradores olharem por traz da cortina.

Eu prefiro muito mais ter vários objetos colaborando entre sí que poucos objetos muito independentes. Essa é a velha discução de Coesão x Acoplamento e Spaghetti x Raviolli.
]]> http://www.guj.com.br/posts/preList/20668/110423.java http://www.guj.com.br/posts/preList/20668/110423.java GMT
Contudo, mandar meu objeto Candidato se gravar no reposítório de dados me cheira muito mal ]]> http://www.guj.com.br/posts/preList/20668/110440.java http://www.guj.com.br/posts/preList/20668/110440.java GMT ]]> http://www.guj.com.br/posts/preList/20668/110445.java http://www.guj.com.br/posts/preList/20668/110445.java GMT
O uso de boas práticas ou não realmente é uma decisão muito séria, mas acho que deve-se conehcer o máximo possível para se saber quando usar e quando não usar.

Não me lembro de nenhum padrão J2EE que não tenha sentido apenas para suprir uma deficiência da plataforma, mas o DAO, IMHO, é mais que isso, age na impedância (cadê o link apra aquele outro tópico?). É ideal? Claro que não, mas funciona (Como DTOs, que até hoje eu busco algo que possa eliminar).

Um DAO deve ler o estado de um objeto e persistí-lo, ou as outras letrinhas do CRUD. Extrair o estado de um objeto apenas com consultas quebra o encapsulamento (a menos que houvessem [url=http://www2.warnerbros.com/friendstv/index.html]"friends"[/url] em Java), mas uma solução para quem procura se manter nas boas práticas é aplicar o pattern [url=http://home.earthlink.net/~huston2/dp/memento.html]Memento[/url] e persistir o Memento. Isso é meio trabalhoso e agrega uma complexidade que, na prática, só vai ser útil para se persistir o objeto.]]> http://www.guj.com.br/posts/preList/20668/110479.java http://www.guj.com.br/posts/preList/20668/110479.java GMT
Este? http://www.guj.com.br/posts/list/20496.java

]['s]]> http://www.guj.com.br/posts/preList/20668/110496.java http://www.guj.com.br/posts/preList/20668/110496.java GMT
Estou lendo o segundo artigo que o AllMighty postou, estou até achando perigoso de tanto que estou adorando o que o cara está escrevendo. Faz um monte de sentido pra mim ]]> http://www.guj.com.br/posts/preList/20668/110502.java http://www.guj.com.br/posts/preList/20668/110502.java GMT
[code]
public class Base<T extends Base> {

public static T find(int id) { ... }
public static Collection<T> find_by_example(T example) { ... }
public static Collection<T> find_by_...

public T save() { ... }
}


public class Candidato extends Base<Candidato> {
private String nome;
public void setNome(String nome) { ... }
public String getNome() { ... }
}[/code]

dai, em algum outro lugar....

[code]Collection<Candidato> foo = Candidato.find(1);
foo.setNome("Coelhinho da Pascoa");
foo.save();[/code]

Fica bonitinho, IMHO :mrgreen:]]> http://www.guj.com.br/posts/preList/20668/110514.java http://www.guj.com.br/posts/preList/20668/110514.java GMT
Interessante esta abordagem. Recentemente montei uma arquitetura pra um sistema que to fazendo e tinha feito algo semelhante.
A parte do save, update, etc eu fiz deste jeito mesmo sem VO e direto no proprio Bean, usando uns commands pra isso. Algo tipo:

[code]public class User extends Bean
private String name;
private String lastName;
...
public void addUser() {
this.session.save(this);
}
[/code]

Onde este atributo session é a implementacao de um interface que criei e tem somente os atributos save, update, delete, get e find. Somente ela reconhece o Dao.
Para a parte das consultas tava usando um ValueListHandle que era usado pelo meu Bean para realizar os find com as restricoes mais especificas. Nao ta gostando pq ia ter que ficar criando as classes do ValueListHandle dentro do bean e propagar a Session. Do jeito que o CV mostrou acho que resolvo meu problema com poucas alteracoes. :P

O que acham desse modelo? :wink:

]['s]]> http://www.guj.com.br/posts/preList/20668/110522.java http://www.guj.com.br/posts/preList/20668/110522.java GMT
*babando*

Contudo, por que um objeto Candidato deveria ser responsável por buscar coleções de outros Candidatos? Por que ele deveria guardar informação sobre qual tipo de Candidato o usuário quer buscar?

E, nesse modelo, como sera possível alterar a classe Base para uma estrutura completamente diferente, baseado numa interface? Não seria melhor algo como
[code]
public class Candidato {
private Base<Candidato> base = factory.getBase();

private String nome;
public void setNome(String nome) { ... }
public String getNome() { ... }
}
[/code]
sendo Base uma Interface?

cv, obrigadíssimo pelo exemplo, vou usá-lo :D]]> http://www.guj.com.br/posts/preList/20668/110523.java http://www.guj.com.br/posts/preList/20668/110523.java GMT

Eu nao sei se rola usar generics em metodos estaticos, alias... se nao der, a ideia do ActiveRecord nao fica tao legal, mas mesmo assim da pra aproveitar.

Por ultimo, concordo que usar um objeto Candidato pra buscar outros, mas usar a [b]classe[/b] Candidato pra buscar fica chique - metodos estaticos bonitinhos e tal ]]> http://www.guj.com.br/posts/preList/20668/110534.java http://www.guj.com.br/posts/preList/20668/110534.java GMT fez sentido pra mim \o/ eeee

Obrigado mesmo cv

Agora o problema grave é mandar esse mega bombado objeto pela rede hehe que tal usar DTO?
*é esafqueaod por shoes*



Procurei o livro do Martim Flower, POOEOoepP, mas não encontrei nada e [b]não[/b] vou comprar ele agora ]]> http://www.guj.com.br/posts/preList/20668/110541.java http://www.guj.com.br/posts/preList/20668/110541.java GMT *é esafqueaod por shoes*[/quote]

Tudo bonitinho pra chegar no final e querer usar DTO.
Naoooooooooooo

Fiquei so com uma duvida sobre o que o CV postou. Quando tu fala:

[quote="cv"]O problema de fazer usando delegacao ao inves de heranca eh que vc tem que declarar os metodos estaticos[/quote]

Era sobre o que eu tinha postado ou do LIPE?

]]> http://www.guj.com.br/posts/preList/20668/110544.java http://www.guj.com.br/posts/preList/20668/110544.java GMT
Quanto à sua implementação fabgp, quem fornecia o objeto session para os Objetos? E como você poderia colocar todos os comandos dentro de uma transação?]]> http://www.guj.com.br/posts/preList/20668/110545.java http://www.guj.com.br/posts/preList/20668/110545.java GMT
Ha, agora entendi.

[quote=LIPE]Quanto à sua implementação fabgp, quem fornecia o objeto session para os Objetos? E como você poderia colocar todos os comandos dentro de uma transação?[/quote]

Essa arquitetura eu usei em um sisteminha com WW, a Session ta sendo disponibilizada pela minha classe Transaction que é criada com um interceptor para as actions e ele seta na minha super-action a instancia dessa transaction.
Depois a session é passada para o bean quando vou executar algo neles.

Tem algumas coisas que nao gostei do modo que montei, mas ainda nao vi uma maneira eficiente de fazer isso. To pensando em como mudar ainda.

]['s]]> http://www.guj.com.br/posts/preList/20668/110555.java http://www.guj.com.br/posts/preList/20668/110555.java GMT
Mas assim fica bem ruim para ter um controle melhor das transações envolvidas, não? Penso assim pois no sistema atual fiz algo semelhante, e quando precisei colocar ações em transações diferentes foi meio dolorido.]]> http://www.guj.com.br/posts/preList/20668/110558.java http://www.guj.com.br/posts/preList/20668/110558.java GMT
Precisa [b]mesmo[/b] mandar ele pela rede? Hmm. Merda. Bom, pega o BeanUtils, taca tudo num HashMap, e passa pela rede. Depois recupera, e tchararaaaaaam!

</solucao-porca>

Se o caso for mandar um objeto pesado pela rede e isso REALMENTE for um problema, DTO eh uma boa ideia. Mas, de novo: DTO [b]so[/b] serve quando voce tem [b]problemas[/b] em passar um objeto pela rede. Entao, antes de usar DTO, voce precisa provar pra si mesmo que o objeto eh grande demais e vai impactar a performance da aplicacao, e olhar pro codigo e falar "argh, ta grande" nao eh uma dessas maneiras.

Um jeitinho massa de saber se voce precisa fazer um DTO ou se vc pode continuar a viver sem a ajuda de aparelhos depois da visitinha do Shoes eh serializar o objeto que vc acha que eh "gordo" demais num arquivo, e ver o tamanho dele. Depois serializar uma quantidade significativa deles, e tirar uma media. Dai da pra ter uma ideia de quantos objetos vc vai conseguir passar pela rede sem melar tudo. ]]> http://www.guj.com.br/posts/preList/20668/110560.java http://www.guj.com.br/posts/preList/20668/110560.java GMT
Isso.

[quote=LIPE]Mas assim fica bem ruim para ter um controle melhor das transações envolvidas, não? Penso assim pois no sistema atual fiz algo semelhante, e quando precisei colocar ações em transações diferentes foi meio dolorido.[/quote]

Açoes tu diz, um save e um delete por exemplo na mesma Transacao?
Nao cheguei a precisar disso, mas confesso que nem tinha pensado nessa possibilidade. Se for isso é bom eu pensar e ver o impacto disso. hehehehe
Se for isso tu achou uma solucao sem doer muito?

]['s]]> http://www.guj.com.br/posts/preList/20668/110565.java http://www.guj.com.br/posts/preList/20668/110565.java GMT Um jeitinho massa de saber se voce precisa fazer um DTO ou se vc pode continuar a viver sem a ajuda de aparelhos depois da visitinha do Shoes eh serializar o objeto que vc acha que eh "gordo" demais num arquivo, e ver o tamanho dele. Depois serializar uma quantidade significativa deles, e tirar uma media. Dai da pra ter uma ideia de quantos objetos vc vai conseguir passar pela rede sem melar tudo. [/quote]

Estes tempos eu fiz um teste semelhante a este, achava que tinha uma colecao de objetos extremamente "gorda", mas o java me desmentiu na lata.

]['s]]> http://www.guj.com.br/posts/preList/20668/110566.java http://www.guj.com.br/posts/preList/20668/110566.java GMT
fabgt, usei uma gambiarra. Nada bonito.


Mais uma dúvida, também em relação à tarefas normalmente realizadas por um DAO: e se uma consulta retorna 2 ou mais tipos de objetos completamente diferentes? Quem deve ser repsonsável pela coisa toda?

No caso de UIs que envolvam mais de um tipo de objeto, sem problemas. Uma classe fica responsável por montar a coisa toda. Seria o mesmo princípio aplicável para o problema acima? Criar uma classe gerenciadora para esses casos especiais? Mas isso não seria um DAO?

]]> http://www.guj.com.br/posts/preList/20668/110580.java http://www.guj.com.br/posts/preList/20668/110580.java GMT ]]> http://www.guj.com.br/posts/preList/20668/110630.java http://www.guj.com.br/posts/preList/20668/110630.java GMT não faz o menor sentido minha pergunta

[img]http://www.patandkat.com/pat/weblog/images/bright-idea-beej-sm.jpg[/img]]]> http://www.guj.com.br/posts/preList/20668/110633.java http://www.guj.com.br/posts/preList/20668/110633.java GMT
]]> http://www.guj.com.br/posts/preList/20668/110663.java http://www.guj.com.br/posts/preList/20668/110663.java GMT [/quote]

Eu já, quer um bom exemplo?

Dada a seguinte query "me retorne os últimos registros que o usuario alterou", ela não retorna os Rastros do usuario, mas sim os DO em questão.]]> http://www.guj.com.br/posts/preList/20668/110684.java http://www.guj.com.br/posts/preList/20668/110684.java GMT

Mas num caso desses o SGBD iria fazer um full scan em todas as tabelas @.@

Não seria uma solução mais apropriada fazer uma tabela de logging, muito bem representável por um objeto?

E considerando a situação que você apresentou, como seria adequado representar este comportamento dentro do sistema?]]> http://www.guj.com.br/posts/preList/20668/110703.java http://www.guj.com.br/posts/preList/20668/110703.java GMT
Eu faria um log com os ids alterados. Depois recuperaria eles e iria em cada lugar pegar eles..


Só pra não passar em branco, eu tb uso o mesmo modelo de Bean do Fabio : cada qual herda do Master o "script de CRUD" o qual retornado, eu pego uma SessionFactory e passo pra ela executar.... meio doido, mas funciona
Hnum, To usando tudo isso com Swing tah, e isso me deixa livre pra fazer uma interface pra apresentar o bean bunitinho na tela

Mas to gostando da discussão...
]]> http://www.guj.com.br/posts/preList/20668/110712.java http://www.guj.com.br/posts/preList/20668/110712.java GMT

Morte ao MVC!
*facilmente convertido*

]]> http://www.guj.com.br/posts/preList/20668/110714.java http://www.guj.com.br/posts/preList/20668/110714.java GMT *facilmente convertido*[/quote]

Qual é o slogan agora? ]]> http://www.guj.com.br/posts/preList/20668/110727.java http://www.guj.com.br/posts/preList/20668/110727.java GMT

Mas num caso desses o SGBD iria fazer um full scan em todas as tabelas @.@

Não seria uma solução mais apropriada fazer uma tabela de logging, muito bem representável por um objeto?

E considerando a situação que você apresentou, como seria adequado representar este comportamento dentro do sistema?[/quote]

Eu já implementei auditoria de 2 formas diferentes, cada qual tinha suas exigencias.

Uma foi usando shadow-tables, era bem facil gerar os dados de auditoria mas era uma saco usar essa informação. A outra foi usando uma tabela só com um campo clob com os valores em pares chave-valor, usa 1 tonelada de disco, mas fica mais facil de pesquisar e implementar usando interceptor do Hibernate foi assustadoramente facil.

Enfim, quanto a query, em ambos os casos os DAOs reconstruiam os DO a partir das informações recuperadas, no final das contas retornavam coleções de objetos heterogêneos mesmo. Existia um AutoriaDao que tinha esses métodos de pesquisa. Eu gosto de criar DAOs por casos de uso e não por DO que são partícipes.

E não tem full-table scan não lipe, vale lembrar que o modelo de dados e o modelo dos objetos de dominio não precisam ser parecidos ou ter coisas equivalentes, basta saber ir de um pro outro.]]> http://www.guj.com.br/posts/preList/20668/110732.java http://www.guj.com.br/posts/preList/20668/110732.java GMT http://www.guj.com.br/posts/preList/20668/110818.java http://www.guj.com.br/posts/preList/20668/110818.java GMT
Por isso eu nao gosto muito de mapear 1 pra 1, uma tabela pra um objeto, nem sempre isso faz sentido com a real necessidade do sistema. Esse exemplo que o Louds deu é um classico onde teu objeto nao tem nada haver com as tabelas do banco.
Acredito que o dominio do objetos deve ficar independete disso, satisfazendo a tua necessidade para as regras de negocio do sistema e o DAO que se vire pra retornar isso coerentemente.

]['s]]> http://www.guj.com.br/posts/preList/20668/110831.java http://www.guj.com.br/posts/preList/20668/110831.java GMT
A alternativa satisfatoria pro DAO, é ORM no estilo do Hibernate usando xdocklet ou annotations, uma pena apenas que ele te obriga a ter getters/setters.

Uma idéia que eu achei muito legal foi uma do Charles Miller de usar IoC para as pesquisas que o teu objeto precisa.]]> http://www.guj.com.br/posts/preList/20668/111030.java http://www.guj.com.br/posts/preList/20668/111030.java GMT
Tem algum artigo sobre louds?

]['s]]> http://www.guj.com.br/posts/preList/20668/111034.java http://www.guj.com.br/posts/preList/20668/111034.java GMT

[url]http://fishbowl.pastiche.org/2004/04/04/cut_with_the_grain[/url]]]> http://www.guj.com.br/posts/preList/20668/111048.java http://www.guj.com.br/posts/preList/20668/111048.java GMT
]]> http://www.guj.com.br/posts/preList/20668/111714.java http://www.guj.com.br/posts/preList/20668/111714.java GMT
[code]
public ActionForward gravar(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response) throws Exception {

DynaActionForm atividadeForm = (DynaActionForm)form;
Atividade atividade = null;

SystemUserSession systemUserSession = new SystemUserSession(request);
BusinessTransaction businessTransaction = getBusinessTransactionFactory().createNewBusinessTransaction((SystemUser)systemUserSession.getModel());

try {
businessTransaction.start();

AtividadeBusiness atividadeBusiness = new AtividadeBusiness(businessTransaction);

atividade = (Atividade)atividadeBusiness.newEntityInstance(
((Long)atividadeForm.get("idAtividade")).longValue()
);
BeanUtils.copyProperties(atividade, atividadeForm);

try {
businessTransaction.beginTransactionalBlock();

atividadeBusiness.save(atividade);

businessTransaction.commitTransactionalBlock();
} catch (BusinessTransactionException bte) {
businessTransaction.rollbackTransactionalBlock();

setAlertMessage(request, be.getMessage());
}
} finally {
businessTransaction.finish();
}

atividadeForm.initialize(mapping);

return mapping.findForward("_FormAtividade");
}
[/code]

Nessa solução que implementei na arquitetura que desenvolvi para fabrica de software que trabalho, criei uma classe responsavel por controlar o escopo (start/finish) e as ações (begin/commit/rollback) das trasações de negócio do sistema.

O fluxo é o seguinte...

1. [b]start()[/b] - cria uma sessão SessionFactory.
2. Vários business-objects podem ser instanciados passando a instância "startada" de [b]businessTransaction[/b] e manipulados.
3. [b]beginTransactionalBlock()[/b] - inicia uma transação do Hibernate (session.beginTransaction()).
(save/remove/get/anyMethod).
5. [b]businessTransaction.commitTransactionalBlock() ou businessTransaction.rollbackTransactionalBlock()[/b] - comita ou descarta a trasação do Hibernate.
6. [b]businessTransaction.finish()[/b] - encerra a sessão do Hibernate.

Obviamente que existem outras classes e interfaces envolvidas na parada, mas o conceito é esse.

Da maneira como estruturei essa arquitetura, fica bastante fácil se amanhã ou depois eu não quiser mais utilizar o Hibernate e passar a usar um outro mecanismo de persistencia, porque toda a estrutura está baseada em [b]interfaces[/b].

Bom espero que ajude... espliquei bem por cima, como disse, tem várias classes e interfaces envolvidas, mas acho que deu para enternder o conceito, né?

Sei que ainda tem várias coisas para serem melhoradas e estou trabalhando todos os dias para fazer isso... :D ...sugestões são bem vindas...

Abraço!]]> http://www.guj.com.br/posts/preList/20668/113217.java http://www.guj.com.br/posts/preList/20668/113217.java GMT
[/quote]

No meu caso eu tinha 1 factory de helpers que providenciavam a view e outras colaborações.]]> http://www.guj.com.br/posts/preList/20668/113226.java http://www.guj.com.br/posts/preList/20668/113226.java GMT Sobre o DAO, de certa forma eh um anti-pattern do jeito que normalmente se ve feito por ai.
[/quote]

qual o jeito certo d fazer DAOs ?]]> http://www.guj.com.br/posts/preList/20668/232100.java http://www.guj.com.br/posts/preList/20668/232100.java GMT
[code]
public class Base<T extends Base> {

public static T find(int id) { ... }
public static Collection<T> find_by_example(T example) { ... }
public static Collection<T> find_by_...

public T save() { ... }
}[/code]
[/quote]

Em java num da pra usar generics em metodos Static! :( ]]> http://www.guj.com.br/posts/preList/20668/260213.java http://www.guj.com.br/posts/preList/20668/260213.java GMT
Por exemplo, se eu tenho uma classe chamada Turma que usa um ArrayList ou uma Hashtable para guardar os alunos:

private ArrayList alunos;

e criar um método getAlunos que retorna esse ArrayList, não seria a mesma coisa que deixar o atributo alunos como público?]]> http://www.guj.com.br/posts/preList/20668/480437.java http://www.guj.com.br/posts/preList/20668/480437.java GMT