Arquitetura: tentativas, sugestões.

This message was edited 2 times. Last update was at 23/03/2005 11:57:39

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

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

Bom, parece normal para mim

Está usando as patterns VO, DAO e Command. Que tal tirar o VO dali?

Rafael Nunes wrote:Aqui no trampo vamos desenvolver um 'framework' pra servir de padrão no desenvolvimento de todos aplicativos(são todos pra uso próprio).

O meu arrepio comecou aqui.

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.

Rafael Nunes wrote: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.

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

E, como uma imagem vale mil palavras, eis a minha descricao mais completa da sua arquitetura ate agora:

Habla chico...

Rafael Nunes wrote:
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.

Segundo isso, você deve ter objetos assim:

AdicionarUsuarioBO
RemoverUsuarioBO
editarUsuarioBO

Certo?

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

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

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.

Olá

Rafael Nunes wrote:
Aqui no trampo vamos desenvolver um 'framework' pra servir de padrão no desenvolvimento de todos aplicativos(são todos pra uso próprio).

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.

2. É óbvio que você conhece muito bem os patterns Template Method, Strategy, Command, FrontController, ServiceToWorker e outros mais.

3. Tenho a certeza que você já estudou e usou muito os frameworks atuais como Struts, Webwork e Spring

4. 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.

[]s
Luca

LIPE wrote:cv, se ele decidiu usar a Pattern Command, é necessário ter um interface comum a todos os comandos, não é?

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.

LIPE wrote: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í.

Sem duvida. So de voce ter parado pra pensar e perguntar sobre isso ja torna o mundo um lugar melhor.

This message was edited 1 time. Last update was at 23/03/2005 13:29:02

Rafael,

O CV disse tudo:

CV wrote:
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.

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.

Refactoring é a palavra mágica

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.

Lipe wrote: Está usando as patterns VO, DAO e Command. Que tal tirar o VO dali?

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?

Lipe wrote:Desenvolver uma maneira padrão para comunicação entre as camadas _poderia_ ser um framework

Bingow, é exatamente isso!!!O que estamos querendo é um padrão para comunicação E desenvolvimento.

Rafael Nunes wrote:
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?

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

cv wrote: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.

É 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

cv wrote:O que acontece se o objeto nao puder seguir o padrao init/execute/finalize

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.

cv wrote: - 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?

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

cv wrote: - finalize() eh um metodo que ja tem na java.lang.Object e serve pra outra coisa. Voce vai ter que arrumar outro nome

Na verdade o nome dele é posCOndicoes(). É que não quis estragar a surpresa... ;o)

Luca wrote: 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.

Acho que não é uma boa hora pra perguntar quem é Rod Johnson...

2. É óbvio que você conhece muito bem os patterns Template Method, Strategy, Command, FrontController, ServiceToWorker e outros mais.

Na verdade só o FrontController, que é o que usamos aqui hoje.

3. Tenho a certeza que você já estudou e usou muito os frameworks atuais como Struts, Webwork e Spring

Struts e Webwork sim, mas acho meio complicado implementar eles pras necessidades que temos aqui.

4. Por fim você realmente precisa reinventar a roda.

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.

pcalcado wrote: 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 )

Na verdade hoje a estrutura está assim, uma máquina com o tomcat rodando os JSP e uma outra rodando os .java

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.

É exatamente isso que eu tentei fazer com meus Business Objects e DAO´s.

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

Hoje já utilizamos o Session Bean pra isso, e provavelmente é o que continuaremos a utilizar, pois não encontrei maneira mais fácil.

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

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

uhhhmmm... Rafael, acho que antes de mais nada, você precisa entender o conceito de "Domain Model" de uma aplicação:

http://www.martinfowler.com/eaaCatalog/domainModel.html

E um dos problemas que causam Domain Models ruins:

http://www.martinfowler.com/bliki/AnemicDomainModel.html

(quantas vezes esse link já foi dado no GUJ?)

This message was edited 1 time. Last update was at 23/03/2005 14:03:07

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.

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