hehe Shoes 
Rafael, então realmente precisa de uma estrutura de comunicação. EJBs fazem o serviço para você, mas se quiser, pode dar uma olhada no DualRpc.
Pode resolver o seu problema com muito mais facilidade.
O Business Delegate não pode ficar na mesma máquina que os JSP/Servlets e invocar os EJB´s via JNDI que aponta pra outra máquina?
Pra que DualRpc?
É que aqui tá sobrando dinheiro e máquinas, então provavelmente terão uma máquina pros servlets e jsp´s; uma máquina pros Business Object e DAO´s, e uma outra máquina pra persistência.
Talvez tenham uma pra jogar paciência nos horários de folga… ;o)
Ao invés de EJBs.
[quote=LIPE]
Ao invés de EJBs.[/quote]
Invés de RMI, tu diz, né?
Tudo a mesma coisa.
Lipe, que está sempre certo.
:XD:
Padrões, Java, J2EE, EJB, Hibernate, Patterns, Domain Model, Anemic Domain Model, DualRPC…
Estou considerando seriamente a possibilidade de ir pro interior vender patos e javali. Aliás, carne de javali é bem saborosa, interessa?
hehe Rafael, por isso simplesmente falei que seu plano parecia bom. Quando começa a entrar nesse mundo, melhor ir devagar, sem se preocupar tanto. Tenha consciência que quanto mais estudar, mais nojo vai ter do código que escreveu.
Por isso, sendo contrário ao que falaram, atenha-se ao seu plano básico. Mas saiba que, sem a experiência necessária, é bastante improvável que saia um framework do seu trabalho todo; é mais provável surgir uma solução completamente engessada e fedida (como aconteceu comigo). E tudo bem! Já que é para aprendizado, se esbalde com seus erros
Felizmente disso eu tenho consciência, que daqui há alguns meses ou anos, vou achar esta minha solução uma afronta a moral e bons costumes. Mas de alguma forma eu tenho de começar.
E em todo caso, sempre haverão patos e javalis… ;o)
Sinceramente, não faz sentido fazer um framework do zero a menos que você esbarre em um problema que não foi resolvido de forma satisfatória. Se você não pode usar outros frameworks, não pode usar Hibernate também 
e, lógico que isso não faz o menor sentido. Assim como escrever um framework do zero por escrever…
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 :mrgreen:
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
[quote]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[/quote]
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.
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?
Ao invés de EJBs.[/quote]
Você ainda pode usar JNDI com classes simples no Container. Não Pode?
Olá
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.
[quote=Rod Johnson, J2EE Design and Development, pág 166]
Why (and How) Not to reinvent the Wheel[/quote]
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?
[quote=Rafael Nunes]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?[/quote]
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.
A gente trabalha com uma plataforma OO, não faria sentido programar proceduralmente com ela.
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?
Sim, pelos motivos acima.