Buenas,
Aqui no trampo vamos desenvolver um ‘framework’ pra servir de padrão no desenvolvimento de todos aplicativos(são todos pra uso próprio).
Pelo que andei conversando com o Philip, o cv, e lendo vários posts daqui e outras coisas mais, modelei mais ou menos como vai ser a arquitetura, gostaria de sugestões e/ou críticas vossas:
Vou ter um objeto que será a base para toda regra de negócio. Ele vai seguir uma sequência de inicialização, execução e finalização, que toda regra de negócio deverá implementar para seguir tal regra. EM outras palavras, vou ter uma interface com três métodos abstratos: init(), execute() e finalize(), e todo Business Object deverá implementar esta interface, e seus métodos.
Vou ter uma camada de DAO, utilizando um objeto padrão(DAOFactory) para as operações básicas de persistência, e esta camada DAO é quem fará a comunicação com a camada de persistência em si. Provavelmente Hibernate ou Entity Beans.
A interface ainda não está definida, mas provavelmente teremos um controle que comunicará a interface com a camada de negócios.
E então, o que eu poderia melhorar?Mudar?Acrescentar?Ou devo largar tudo e montar uma banca de jornal?
Obs:Sei que é meio vago definir uma arquitetura sem conhecer o negócio o qual ela servirá, mas é só pra fazer uma certa idéia do que seguir.
Grato
Desenvolver um framework ANTES de desenvolver uma aplicacao nao da certo: ou voce acaba com a aplicacao tendo que fazer gambiarras em cima do framework, ou a aplicacao nao sai ate mudarem o framework. Eh melhor fazer uma aplicacao primeiro, refatorar ela e tirar os pedacos genericos e transformar num framework do que tentar advinhar o que eh generico e o que nao eh. Alias, risque a palavra advinhar do dicionario.
[quote=Rafael Nunes]Pelo que andei conversando com o Philip, o cv, e lendo vários posts daqui e outras coisas mais, modelei mais ou menos como vai ser a arquitetura, gostaria de sugestões e/ou críticas vossas:
Vou ter um objeto que será a base para toda regra de negócio. Ele vai seguir uma sequência de inicialização, execução e finalização, que toda regra de negócio deverá implementar para seguir tal regra. EM outras palavras, vou ter uma interface com três métodos abstratos: init(), execute() e finalize(), e todo Business Object deverá implementar esta interface, e seus métodos.
Vou ter uma camada de DAO, utilizando um objeto padrão(DAOFactory) para as operações básicas de persistência, e esta camada DAO é quem fará a comunicação com a camada de persistência em si. Provavelmente Hibernate ou Entity Beans.[/quote]
Bom, algumas observacoes:
O que acontece se o objeto nao puder seguir o padrao init/execute/finalize?
Por que um objeto de negocios - que trata de uma regra de negocio especifica - vai ter que implementar uma interface alien dessa, que modela coisas que sao inicializaveis, executaveis e paraveis, sem necessariamente serem inicializaveis, executaveis ou paraveis?
Por que ter uma “camada” de DAOs se voce nem sabe de que tipo de persistencia e nem de que tipo de queries voce precisa?
finalize() eh um metodo que ja tem na java.lang.Object e serve pra outra coisa. Voce vai ter que arrumar outro nome :mrgreen:
E, como uma imagem vale mil palavras, eis a minha descricao mais completa da sua arquitetura ate agora:
Se isso é verdade, me diz qual a diferença entre isso e um design procedural com funções com os mesmos nomes? (nota: esse excesso de Commands é sintoma de uso de Struts… acertei?)
Antes de pensar nas ações tomadas pelo sistema, pense nos objetos do sistema. Ops, problema aí: como pensar em objetos de sistemas futuros?
Fazer um framework tão genérico e manter boas práticas não é muito fácil… mais fácil você manter umf ramework vertical, sobre aquilo que sua emrpesa costuma ldiar (objetos relacionados ao negócio).
Se você trabalha com telecom, por exemplo, provavelmente vai conseguir ter uns objetos Assinante, BaseTerrestre, blablabla reutilizáveis, mas eles vêm com o tempo
Acho que você está se preocupando muito com o RAD da coisa
cv, se ele decidiu usar a Pattern Command, é necessário ter um interface comum a todos os comandos, não é?
E Rafael, apesar dos exelentes comentários de ambos, não se desespere, o jeito que você fez é melhor do que muita coisa por aí.
Sobre o comentário do cv sobre fazer a solução antes de surgir o problema, esclareço uma coisa a você: MVC não é um framework. Desenvolver uma maneira padrão para comunicação entre as camadas poderia ser um framework.
Aliás, tem certeza que não há algo pronto no mercado para a necessidade de vocês? Se o objetivo é produção e não aprendizado, há o Genesis.
[quote=Rafael Nunes]
Aqui no trampo vamos desenvolver um ‘framework’ pra servir de padrão no desenvolvimento de todos aplicativos(são todos pra uso próprio).[/quote]
Suponho que além do obrigatório e basico Effective Java, você leu os 2 livros do Rod Johnson e percebeu claramente o trampo que virá pela frente.
É óbvio que você conhece muito bem os patterns Template Method, Strategy, Command, FrontController, ServiceToWorker e outros mais.
Tenho a certeza que você já estudou e usou muito os frameworks atuais como Struts, Webwork e Spring
Por fim você realmente precisa reinventar a roda.
Se respondeu sim a todas as 4 afirmações então siga em frente e boa sorte.
Sim, o ponto eh que Command != Business Object… Command eh um metodo transformado em classe, pra poder ser tratado com uma granularidade um pouco diferente, ou quando voce tem parametros meio confusos e quer simplificar a coisa. Usar esse pattern pra “representar tudo” eh meio pisada de bola (de novo, olhem pra foto do cachorro) - e eh um dos defeitos do Prevayler, inclusive.
Sem duvida. So de voce ter parado pra pensar e perguntar sobre isso ja torna o mundo um lugar melhor. :mrgreen:
Todo o framework tem um determinado nível de “genericidade”, ou seja, ele é generico e configurável até certo ponto. Como o framework é para a sua empresa e nada mais, eu sugiro vc criar o framework fortemente acoplado as decisões da sua empresa.
Lembre-se que se acontecer alguma mudança nessas decisões, alguém da sua empresa pode alterar o framework em nível de código fonte. Vc não precisará criar inúmeros arquivos de configuração para utilizar o framework, e com isso, você ganha muito tempo de desenvolvimento.
Em outras palavras, fazer coisas genéricas nem sempre é a melhor saída, porque, além de esperar por uma mudança que talvez nunca aconteça, é possível que o código ainda esteja errado.
Como disse o CV, crie o seu framework ao longo do tempo em que desenvolve o sistema. Assim que detectar que algo pode ser “genérico” você o faz e separa dos fontes da aplicação.
Hun, deixa eu dividir por partes então.
Acho mais fácil situar-me primeiro. Onde trabalho é uma Universidade, logo, tudo que for desenvolvido é pra uso próprio. Já respondendo a última proposição do Lipe, usar algo terceiro está fora de cogitação, o que eles querem mesmo é desenvolver um framework, um padrão que deverá ser seguido por todas aplicações aqui desenvolvidas.
O VO que se refere é o Controller?
Bem o sistema aqui é distribuído, os .jsp ficam em máquina separada dos .class. Iremos usar um Session Bean para comunicação entre a View e o restante da aplicação, sendo que não conheço maneira mais simples de comunicação RMI. Aliás, eu consigo conversar com o Hibernate através de RMI?
Bingow, é exatamente isso!!!O que estamos querendo é um padrão para comunicação E desenvolvimento.
[quote=Rafael Nunes]
O VO que se refere é o Controller?
Bem o sistema aqui é distribuído, os .jsp ficam em máquina separada dos .class. Iremos usar um Session Bean para comunicação entre a View e o restante da aplicação, sendo que não conheço maneira mais simples de comunicação RMI. Aliás, eu consigo conversar com o Hibernate através de RMI?[/quote]
JSP longe dos .class?
Isso me diz que você está usando JSP como se fosse ASP, e isso por si só já é um problema
(aliás, conceitualmente isso não é possível, já que suas JSP viram .class )
Passando ao próximo passo, sua camada de View não deve contatar a camada onde o Hibernate está localizado, para isso coloque uma camada de modelo/negócios no meio.
Nessa camada ficam os objetos de domínio, para acessá-la você pode até utilizar um Stateless Session Bean se estiverem em computadores diferentes, ams não faça isso se não souber quando NÃO utilizar um EJB
Logo, não tem proque voc~e acessar o hibernate, DAOs e etc. pela View, se você precisar colocar sua camada de persistência numa máquina diferente, é outro papo, mas aidna assim a comunicação é entre a camada do meio e a de persistência
É exatamente isso Carlos, queremos criar por exemplo um padrão para todas aplicações por exemplo conversarem com o banco. Estamos entre duas opções, Hibernate e Entity Beans. Ou seja, toda aplicação, ou todo processo que quiser conversar com o banco, deverá passar pelo DAO e este conversará com o Hibernate/Entity
Como assim?Isto não será por objeto, e sim por caso de uso, os métodos serão na verdade preCondicoes(), execute() e posCondicoes(). Onde serão responsáveis respectivamente por executar pré condições antes do caso de uso, executá-lo em si, e alguma tarefa que deva ser executada após a sua finalização.
A persistência será Hibernate ou Entity Beans, o que não quero e creio que não seria recomendável, é dentro do meu objeto de negócio chamar diretamente os métodos do Hibernate/Entity
Na verdade o nome dele é posCOndicoes(). É que não quis estragar a surpresa… ;o)
[quote=Luca] 1. Suponho que além do obrigatório e basico Effective Java, você leu os 2 livros do Rod Johnson e percebeu claramente o trampo que virá pela frente.
[/quote]
Acho que não é uma boa hora pra perguntar quem é Rod Johnson…
Na verdade só o FrontController, que é o que usamos aqui hoje.
Struts e Webwork sim, mas acho meio complicado implementar eles pras necessidades que temos aqui.
O que ando um pouco receoso é de usar uma porrada de frameworks e componentes terceiros e acabar tendo de ajustar minhas aplicações pras necessidades deles.
[quote=pcalcado] JSP longe dos .class?
Isso me diz que você está usando JSP como se fosse ASP, e isso por si só já é um problema
(aliás, conceitualmente isso não é possível, já que suas JSP viram .class ) [/quote]
Na verdade hoje a estrutura está assim, uma máquina com o tomcat rodando os JSP e uma outra rodando os .java
É exatamente isso que eu tentei fazer com meus Business Objects e DAO´s.
Hoje já utilizamos o Session Bean pra isso, e provavelmente é o que continuaremos a utilizar, pois não encontrei maneira mais fácil.
Acho que não me expliquei direito. É exatamente isso que não quero fazer, convesar diretamente minha View com minha camada de persistência. Por isso que coloquei os BO e DAO´s. E provavelmente teremos a camada de persistência em uma outra máquina e pra isso acho que será mais Session Beans pra conversar DAO com Persistência
Vou dar uma lida nestes artigos.(O que provavelmente vai me obrigar a abrir uma outra thread pra tirar as dúvidas que certamente terei).
Só para mim, acho que você já recomendou umas 10 vezes esse link…
Edit:
A impresão que tenho olhando essa pseudo-arquitetura que fiz, é que posso gerar um enorme trabalho desnecessário, ou engessar demais o desenvolvimento das aplicações, como o cachorro do cv. Mas é só uma impressão, tipo que eu to sempre esquecendo algo quando saio pra viajar. Talvez sim, talvez não.
É que neste caso, ao menos na estrutura da aplicação que ja tem rodando aqui, os servlets estão na mesma máquina do JSP, o que está em máquina diferente são os EJB´s e Business Objects.
Esse negóciod e tabelas é engraçado… vamos colcoar tudo em tabelas e as manipular! Claro, mas… não é isso que programas estruturados fazem com registros, struts, resultsets, datasets…?
