Arquitetura: tentativas, sugestões.

Forum Spammer Membro desde: 12/03/2003 11:25:57 Mensagens: 4641 Offline

Michael, um framework pode ser a soma de outros frameworks também oras. Contudo, considerando isso, tem razão sobre o uso deles; o Rafael poderia muito bem usar Webwork de um lado, a parte de comunicação do Genesis no meio e Hibernate no fim.

Mas aí o aprendizado seria bem menor. Pense nos pobres patinhos

Virtual Machine Man Membro desde: 18/03/2005 16:13:17 Mensagens: 721 Offline

Michael, um framework pode ser a soma de outros frameworks também oras

Nunca disse que não Ele é que mencionou antes nessa thread que não podia usar frameworks de terceiros. Isso que quis enfatizar: não faz sentido não usar!

Inclusive, a melhor solução a longo prazo sempre acaba sendo construir um framework em cima de outros frameworks que você usa nos seus projetos. Mas isso só pode ser feito após alguns projetos

o Rafael poderia muito bem usar Webwork de um lado, a parte de comunicação do Genesis no meio e Hibernate no fim.

Mas aí o aprendizado seria bem menor

Não. Depende do que você quer aprender. Se você faz tudo no braço (inclusive a persistência), você aprende as coisas no nível mais baixo, mas a tendência é que sua "overall architecture" seja uma porcaria. E, no dia a dia, é (geralmente) muito mais importante que você saiba escrever uma solução clara e fácil de manter, não a que é mais eficiente que o Hibernate, por exemplo.

Tava considerando aqui a utilização de um framework tipo Webwork, pra fazer o controle. Mas acho que ele iria gerar um trabalho desnecessário.
O que ele faria é simplesmente direcionar as chamadas da View pra camada dos Business Object. Aí lá vinha mais bibliotecas, mais xml, mais configuração, e isso eu poderia resolver com um simples servlet, estou errado?

Só um comentário sobre o uso indiscriminado do padrão Command, e o sistema altamente procedural resultante.

Eu conheço um certo sistema produzido com algo muito próximo dessa estrutura que você sugeriu, só que ele usa Session Beans como os "business objects" do framework que vc fez.

Resultado? Hoje existem quase 400 Session Beans, cada um faz uma coisa apenas (adiciona usuário, remove usuário), o deployment descriptor é ilegível (ok, nenhum descriptor é lá muito legível...) e simplesmente não escala.

This message was edited 1 time. Last update was at 23/03/2005 16:56:01

Hoje a gente já tem um ERP aqui que utiliza esse pattern Command. Utiliza Session Bean também, porém os Session Beans utilizam um Façade, só implementam um método que chama um business object.
E temos um Session Bean por módulo, por exemplo, um Session Bean pra módulo financeiro, um Session Bean pra módulo acadêmico, outro pra relatório.
Ao invés de termos um Session Bean pra cada caso de uso, temos um Session Bean com milhares de métodos, e esses chamam os objetos de negócio.

Ps:Tá muito 'procedural' esta arquitetura?

LIPE wrote:

danieldestro wrote:Pra que DualRpc?

Ao invés de EJBs.

Você ainda pode usar JNDI com classes simples no Container. Não Pode?

Olá

Rafael Nunes wrote:
Acho que não é uma boa hora pra perguntar quem é Rod Johnson...

Rod Johnson, autor de J2EE Design and Development, um dos melhores livros de arquitetura J2EE que conheço e cujo capítulo 4 é de leitura obrigatória para todo cara que pretende escrever código Java além do Hello World. Ele escreveu também J2EE Development without EJB e é o criador do Spring.

Rod Johnson, J2EE Design and Development, pág 166 wrote:
Why (and How) Not to reinvent the Wheel

São cerca de cinco páginas dizendo o que o CV já disse, que eu repeti e o Michael corroborou.

Eu sou tão fã do Rod Johnson que vou afirmar o seguinte: assim como alguns dizem que programador Java que nunca leu Effective Java tem grande chance de escrever código merda e ilegível, arquiteto de sistemas que nunca leu Rod Johnson tem grande chance de criar sistemas dificeis de manter e extender (como casas que não servem para morar).

E finalmente os patterns que citei são os mínimos necessários para escrever um framework meia boca. Se você não conhece Template Method e Strategy tem grande chance de também nunca ter ouvido falar em inversão de controle. O Service To Worker é como o Command é usado pelos frameworks para preparar a resposta dinâmica para a camada de apresentação. A importância de conhece-lo bem é para não usar Dispatcher View que viola o MVC.

[]s
Luca

Grato, vou dar uma olhada nesses patterns.

Eu acho que acabei usando o termo errado, creio eu que o que estou fazendo não é bem um framework, é tipo criar um padrão, um contrato para o desenvolvimento das aplicações internas.
Andei reavaliando o esquema todo, e me incomodou um pouco esta estrutura de Command, de toda regra que negócios ter de seguir um fluxo herdado da interface. Mas me incomoda mais ainda deixar o desenvolvimento dos objetos de negócio a esmo, não criar um contrato para isso. Principalmente porque a maioria dos programadores são ou vieram do mundo procedural, o que eu queria era tipo obrigá-los a programar OO(sim, eu sei que é bem difícil eu conseguir isso se não houver um comprometimento deles, e não, ameaças de morte/demissão/desconto de salário não são viáveis neste caso).

Alguma sugestão?

Rafael Nunes wrote:Grato, vou dar uma olhada nesses patterns.

Eu acho que acabei usando o termo errado, creio eu que o que estou fazendo não é bem um framework, é tipo criar um padrão, um contrato para o desenvolvimento das aplicações internas.
Andei reavaliando o esquema todo, e me incomodou um pouco esta estrutura de Command, de toda regra que negócios ter de seguir um fluxo herdado da interface. Mas me incomoda mais ainda deixar o desenvolvimento dos objetos de negócio a esmo, não criar um contrato para isso. Principalmente porque a maioria dos programadores são ou vieram do mundo procedural, o que eu queria era tipo obrigá-los a programar OO(sim, eu sei que é bem difícil eu conseguir isso se não houver um comprometimento deles, e não, ameaças de morte/demissão/desconto de salário não são viáveis neste caso).

Alguma sugestão?

Matá-los'

'

talvez fosse interesante mostrar porque eles deveriam aprender OO?
em que esta padronização sua melhoraria todo o processo?
E a você se realmente é necessária uma mudança nesse sentido?

Caso consiga algum volutário depois disso

pode iniciar com eles, com o tempo os demais vão se juntando ao grupo.

talvez fosse interesante mostrar porque eles deveriam aprender OO?

A gente trabalha com uma plataforma OO, não faria sentido programar proceduralmente com ela.

em que esta padronização sua melhoraria todo o processo?

Hoje temos uma equipe de 9 programadores, todos vieram e ainda programam em tecnologias procedurais. O problema é que hoje na hora do desenvolvimento, cada um cria as classes, os objetos a esmo. Acha o jeito mais fácil ou mais cômodo de fazer e sair criando classes e métodos. Pode imaginar como está a arquitetura e manutenção desta aplicação?

E a você se realmente é necessária uma mudança nesse sentido?

Sim, pelos motivos acima.

Uma sugestão que pode ajudar em casos assim, mas não é todo mundo que pode, é contratar um consultor especializado.

Só cuidado com picaretas, e essa é a parte difícil em contratar um consultor. Desconfie de muitas siglas de empresas e certificações pop.

Rafael Nunes wrote:Principalmente porque a maioria dos programadores são ou vieram do mundo procedural, o que eu queria era tipo obrigá-los a programar OO(sim, eu sei que é bem difícil eu conseguir isso se não houver um comprometimento deles, e não, ameaças de morte/demissão/desconto de salário não são viáveis neste caso).

A sugestao do Kiviano eh otima, mas esconder os corpos eh sempre uma tarefa ingrata. O que voce pode fazer eh uma workshopzinha rapida de Test-Driven Development, e rejeitar qualquer codigo no CVS que nao tenha um teste unitario provando que ele deve existir, e que ele funciona. Enfase no "provando que ele deve existir", por favor.

Demora uma ou duas semanas pra montar um sistema de build automatizado que toma conta disso pra voce, caso voce nao tenha nenhuma experiencia com a coisa (de uma olhada no DamageControl, CruiseControl e CruiseControl.NET).

Isso, por si so, ja aumenta a qualidade do codigo - mesmo que seja uma porcaria nao-OO, pelo menos voce sabe se funciona ou nao inspecionando os testes unitarios, e como tem sempre uma base de testes por perto, fica facil refatorar e fazer a coisa mais OO.

Outro esquema que pode ajudar bastante eh se livrar de metade das maquinas da sala, e botar todo mundo pra fazer pair programming. Assim, a comunicacao na equipe aumenta, e a troca de conhecimentos e aprendizados se agiliza. Dai, ja que voce ta fazendo integracao continua e pair programming, mesmo, aproveite pra dar uma lida sobre XP, e adapte as ideias que mais convierem (ou force aqueles que decidem esse tipo de coisa a adota-las. Armas apontadas pra cabeca do individuo e/ou familiares dele geralmente resolvem essas decisoes com uma eficacia incrivel)

Moderador Membro desde: 21/02/2003 16:19:19 Mensagens: 1644 Offline

cv wrote:Demora uma ou duas semanas pra montar um sistema de build automatizado que toma conta disso pra voce, caso voce nao tenha nenhuma experiencia com a coisa (de uma olhada no DamageControl, CruiseControl e CruiseControl.NET).

Samuel esnobe diz que nao demora nao

Montei o ambiente em 4 dias com DamageControl, Maven, CVS e Eclipse. Ficou bem legal (servidor HPUX rodando DC e Maven, repositorio central do Maven para desenvolvedores e servidor, CVS em outro servidor e Eclipse para desenvolvimento) ... recomendo, o trabalho de manutencao é incrivelmente baixo (quase nulo) depois que estiver tudo redondo.

smota, quer tentar "implantar" essa idéia aqui? PVT-me.

Rafael Nunes wrote:
Sim, pelos motivos acima.

Fiz as indagações porque hoje há um grande BOOM entorno de OO,
Padrões, e bla bla, e ta cheio de especialistas nisso

Aqui mesmo quando aparece um cara querendo saber fazer uma
jsp + servlet, ja aparecem vários experts mandando o cara estudar padrões,
que isso ta erado, que aquilo ta á errado.

PS: foi ironia mesmo...

Enfim, você nunca vai chegar a usar padrões se não sabe OO,
e isso vale para seus desenvolvedores.
A curva de aprendizado é muito ingrime, e quando você chegar ao topo dela,
vai olhar pra baixo e dizer "putz, subi um degrau",
ai quando tiver chegando no segundo vai olhar pra traz e dizer "putz, meu primeiro degrau não suporta o segundo"
vamos reestudar, refatorar, reeaprender, e assim o ciclo segue.

Só queria atentar ao fato de que não use OO, não use, Padrões,
não use qualquer coisa se não tiver certeza de que no futuro vai agregar algum valor,
e se não souber o que está fazendo.

Do contrário continuará programando estruturalmetne o resto da vida mesmo usando Java.
Ou acham que quem usa Java obrigatoriamente programa OO?

é preciso tomar cuidado quando se diz vamos programar OO,
maravilha, somos fodas, ai agente põe uns padrõezinhos aqui e
ali e fica show. Que show : ))

no mais estude OO(sempre), padrões(sempre), e atentando ao fato de que sempre mudam, e que NÃO deve adotar a idéia de alguém completamente, mesmo este sendo O CARA, formule as suas idéias, e proponha novas idéias.

PS2: saiu uma redação

PS3: foi um desabafo sim

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