Refatorando o JForum - ajuda com a arquitetura

This message was edited 1 time. Last update was at 11/04/2005 19:12:53

Rafael Steil wrote:
Bom, mas no fundo ainda existiria os respectivos metodos no dao, nao?! (mesmo que eles fossem chamados por algum observer)
Rafael

Eu vejo a camada de DAO fazendo somente o plumbing entre banco e aplicação. Os métodos devem ser, em geral, atômicos e não produzir qualquer efeito colateral além do óbvio.

Então sim, os daos continuariam tendo os métodos para falar com a base de dados e fazem nada além disso.

Quanto ao comentario sobre o delete. Eu ignorei detalhes sobre caching para simplificar a coisa, supondo que você tem somente o topic_id, não tem como evitar ir ao banco, certo? Essa era minha sugestão, se precisar fazer um select count() melhor mandar o delete ou update direto. Com mysql < 4.1 acho que rola fazer uma gambiarra com multi-table delete/update para burlar a falta de subqueries.

Certo, concordo.

Em relacao ao caching, o que eu comecei a fazer tambem eh criar uma implementacao cached do DAO, que fica na frente da implementacao concreta. Atualmente, o codigo esta assim:

Com o refactoring, somente vai existir a chamada ao delete() do ForumDAO. A estrutura eh assim:

*) Eh criada uma instancia concreta do dao
*) Cria-se uma instancia do CachedDAO
*) CachedDao recebe uma referencia do dao concreto (decora ele?)

ps: isso, obivamente, fica definido nos arquivos de configuracao. Ai, o CacheForumDAO fica assim:

o cliente nunca ira saber da existencia do cache, ja que vai solicitar uma instancia do dao ao factory e chamar um "unico" metodo.

Rafael

Isso é um decorator, exatamente. Legal.

Smalltalk Membro desde: 06/02/2012 20:41:01 Mensagens: 1 Offline

Estava lendo este tópico antigo e gostaria saber se atualmente o código do Jforum que está no Github pode ser considerado um bom exemplo de arquitetura ou ainda há muito código da versão antiga que precisa de melhorias e refatoração ?

https://github.com/rafaelsteil/jforum3

Estou procurando alguns projetos maiores de código aberto usando padrão MVC para verificar como foram feitas as implementações do controller, serviços , autorização, etc. Exemplos mais didáticos as vezes não mostra muito claramente como resolver alguns problemas mais práticos, por exemplo, uma view que tem um grande número de dependências, no JForum, por exemplo, há construtores com uns 10 parâmetros.

robsp,

a maior parte do código do JForum 3 é novo, e que foi reutilizado foi aprimorado na medida do possível até o momento. Tem algumas coisas lá (como o esquema de serviços) que estou reavaliando a implementação, pois o que tinha em mente no início era ter toda uma API desconectada do ambiente Web, mas hoje em dia vi que era algo meio idiota querer chegar em tal ponto. Isso não significa que está ruim, é mais uma questão conceitual.

A respeito dos construtores dos Controllers, ao meu ver não tem muito como fazer diferente.. talvez, em alguns casos bem especificos, daria para diminuir esse número se algumas das dependências fossem diluídas por outros componentes, mas isso precisa ter uma finalidade bem específica. Querer diminuir só porque parece ter "bastante" é um motivo muito fraco, que pode acabar causando confusão em outras pontas se você não prestar atenção na maneira de refatorar.

Rafael

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