Arquitetura de Projeto. Sugestões!

Bom dia senhores,
Vamos desenvolver um tipo de framework ou nem mesmo isso, somente uma padronização para o desenvolvimento do ERP aqui da empresa.
É uma instituição de ensino, e já há hoje um sistema funcionando com uma arquitetura um tanto estranha, decidimos então modificar a estrutura:

Vou perguntar por partes que acho melhor de discutirmos:
Persistência - Eu havia sugestionado o uso para persistência de Entity Beans, e também os Design Patterns DAO e ValueObject, talvez Business Delegate(mas achei esse um tanto dispensável, pois o VO já poderia fazer este papel). O que vocês acham desta 'combinação'? Alguém tem alguma outra sugestão?

Grato
Rafael

Rafael Nunes wrote:
Vou perguntar por partes que acho melhor de discutirmos:
Persistência - Eu havia sugestionado o uso para persistência de Entity Beans, e também os Design Patterns DAO e ValueObject, talvez Business Delegate(mas achei esse um tanto dispensável, pois o VO já poderia fazer este papel). O que vocês acham desta 'combinação'? Alguém tem alguma outra sugestão?

Sugestão: *Não* use EJB, muito menos CMP (session até é considerável, SE for o caso..)

DTO e Business Delegate têm funções diferentes. DTO é uma gambiarra para passar dados (me recuso a chamar aquilo de objeto!) pela rede, BusinessDelegate encapsula suas chamadas ao servidor para o cliente em operações simples, é uma Façade do lado do cliente

[]s

Aqui estamos usando na atual arquitetura Session Bean Stateless, e a performance está até que boa, por que voc~e não recomenda o uso de EJB? Quanto ao DTO, tem uma sugestão melhor do que DAO+VO? Pois quase todo projeto que conheço, utilizam isso.

Valeus,
Rafael

Eu não usaria DTO nos DAOs, a menos que o modelo relacional já estivesse pornto antes, ou se algum DBA pentelho resolvesse fazer uma loucura qualquer. Mesmo assim, fica meio procedural demais um DAO trabalhar com bandos de dados (DTOs) ao invés de objetos.

EJBs são uma dor de cabeça muito grande e não valem a pena. Para uma boa leitura crítica:

http://c2.com/cgi/fullSearch?search=ejb

Qualquer busco no Google traz muitos artigos sobre as limtiações da arquitetura, e seu porblemas.

Eu pessoalmente acho que se bem arquiteturado, o treco pdoe acabar funcionando, mas nunca vi algo bem feito que envolvesse EJBs, e sofro com um zilhão de Session Beans que alguém resolveu criar, quando podia ter feito tudo num Spring + Hibernate...

[]s

pcalcado wrote:Eu não usaria DTO nos DAOs, a menos que o modelo relacional já estivesse pornto antes, ou se algum DBA pentelho resolvesse fazer uma loucura qualquer. Mesmo assim, fica meio procedural demais um DAO trabalhar com bandos de dados (DTOs) ao invés de objetos.

Mas o DAO não faria o contrário? Pelo que entendi o DAO é quem vai passar os dados para o DTO e este sim transformá-los em objetos. O modelo relacional já esta pronto sim, pois teremos de usar o mesmo da estrutura que está hoje.

pcalcado wrote:EJBs são uma dor de cabeça muito grande e não valem a pena. Para uma boa leitura crítica:

http://c2.com/cgi/fullSearch?search=ejb

Qualquer busco no Google traz muitos artigos sobre as limtiações da arquitetura, e seu porblemas.

Vou dar uma pesquisada nisso agora, pra poder opinar melhor.

pcalcado wrote:Eu pessoalmente acho que se bem arquiteturado, o treco pdoe acabar funcionando, mas nunca vi algo bem feito que envolvesse EJBs, e sofro com um zilhão de Session Beans que alguém resolveu criar, quando podia ter feito tudo num Spring + Hibernate...

[]s

Aqui estamos usando session bean, mas não acho tanto sofrimento, pois para cada 'processo' criamos um session bean, na minha opinião o único empecilho nisso é a porrada de métodos que se implementa em cada um, ficando completamente confusa a classe.
Quanto ao Spring eu não conheço, mas eu estava cogitando o uso do Struts no controller. Vou dar uma olhada no Spring também.

Rafael Nunes wrote:
Mas o DAO não faria o contrário? Pelo que entendi o DAO é quem vai passar os dados para o DTO e este sim transformá-los em objetos. O modelo relacional já esta pronto sim, pois teremos de usar o mesmo da estrutura que está hoje.

O DAO persiste objetos em algum lugar, arquivos CSV, tabelas relacionais.. onde quer que seja. Sua responsabilidade seria converter objetos para o registros (ou seja lá como eles ficam na sua persistência) e trazê-los de volta.

O DTO é usado para diminuir transações muito pequenas, quando você precisa enviar pela rede um objeto muito pequeno cujo custo de transporte é maior que o benefício que aquele objeto traz. Aí você faz uma gambiarra juntando esse objetinho com outras coisinhas que você precisa transmitir na rede naquele momento num objetão e manda. Isso é um problema de coesão enorme, coesão concidental, creio (o pior tipo!), mas tudo bem, 'funciona'...

Rafael Nunes wrote:
Vou dar uma pesquisada nisso agora, pra poder opinar melhor.

Boa

Rafael Nunes wrote:
Aqui estamos usando session bean, mas não acho tanto sofrimento, pois para cada 'processo' criamos um session bean, na minha opinião o único empecilho nisso é a porrada de métodos que se implementa em cada um, ficando completamente confusa a classe.
Quanto ao Spring eu não conheço, mas eu estava cogitando o uso do Struts no controller. Vou dar uma olhada no Spring também.

Um Session Bean por 'operação' é o fim da picada, eu tenho um sistema com 220 session beans do tipo AddSubscriberBean, DeleteSubscriberBean... estude arquitetura de componentes, se puder comrpe o livro do Cheesman (é baratinho, pelo menos pra um livro improtado, e tem em qualquer livraria mcdonald's) e siga a metodologia que ele propõe (pessoal do Rio, sugiro curso do CCE/PUC com Prof. Rodrigues).

O Spring é porreta, mesmo se não for usar agora, leia sobre ele.

[]s

Também não gosto de usar VO ou DTO como queiram. Alguns links interessantes do pq disso.

AnemicDomainModel

DomainModel vs DTO

http://domaindrivendesign.org

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

http://www.guj.com.br/forum/viewtopic.php?t=11147&postdays=0&postorder=asc&start=15

http://www.javafree.com.br/forum/viewtopic.php?t=7995&highlight=domain+model

]['s

Virtual Machine Man Membro desde: 09/05/2003 00:32:03 Mensagens: 607 Offline

Aqui nós utilizavamos ais ou menos a arquitetura que tu falastes, Rafael...

Entre as camadas usávamo VOs, entretanto chegou uma determinada hora que ficou impraticável (exatamente como o pcalcado falou, cheio de SessionBeans para todas as funções básicas). Agora tiramos praticamente todos os SessionBeans, temos apenas dois, utilizamos os próprios objetos do hibernate no lado cliente (evitando assim conversões desnecessárias entre VO e Beans do hibernate). E o objeto responsável no cliente para executar funções diversas é na realidade um proxy que executa funções no lado servidor...

Não sei se foi possível o entendimento dessa engronha que eu escrevi aí, mas eu tentei

!!

Fallow

This message was edited 1 time. Last update was at 12/11/2004 10:15:19

pcalcado wrote:Um Session Bean por 'operação' é o fim da picada, eu tenho um sistema com 220 session beans do tipo AddSubscriberBean, DeleteSubscriberBean... estude arquitetura de componentes, se puder comrpe o livro do Cheesman (é baratinho, pelo menos pra um livro improtado, e tem em qualquer livraria mcdonald's) e siga a metodologia que ele propõe (pessoal do Rio, sugiro curso do CCE/PUC com Prof. Rodrigues).

Pro processo não por operação, por exemplo, tem um SessionBean responsável pelos relatórios, um pela parte de cadastros, outro para contabilidade, etc. O ruim disto é como eu falei, que o SessionBean fica empanturrado de métodos.Vou dar uma olhada melhor no Hibernate também, pra considerar a utilização.

pcalcado wrote:
O Spring é porreta, mesmo se não for usar agora, leia sobre ele.

[]s

Na realidade a parte do Controller e view ainda não decidimos nada, na verdade não decidimos nada da arquitetura toda, mas vou abrir depois um outro tópico para discutir sobre a parte de controller

TedLoprao wrote: E o objeto responsável no cliente para executar funções diversas é na realidade um proxy que executa funções no lado servidor...
Não sei se foi possível o entendimento dessa engronha que eu escrevi aí, mas eu tentei !!

Fallow

Não entendi esta parte de executar a funções no servidor por um proxy.

Grato.

Rafael Nunes wrote:
Pro processo não por operação, por exemplo, tem um SessionBean responsável pelos relatórios, um pela parte de cadastros, outro para contabilidade, etc. O ruim disto é como eu falei, que o SessionBean fica empanturrado de métodos.Vou dar uma olhada melhor no Hibernate também, pra considerar a utilização.

Raael, procure sobre Projeto de Componentes. Esta disciplina ajuda muito a decidir como sua aplicação itnerage, que operações exibe, comoe stão agrupadas... O livro que indiquei é sobre isso, de maneira *muito* prática.

[]s

Virtual Machine Man Membro desde: 09/05/2003 00:32:03 Mensagens: 607 Offline

Rafael Nunes wrote:
Não entendi esta parte de executar a funções no servidor por um proxy.
Grato.

É que no meu caso o lado cliente é swing e utilizamos um proxy para simular que o objeto é local para o swing, quando na verdade os métodos são passados para o servidor executar. Ou seja, quem estiver desenvolvendo o lado cliente requisita um Business Object e aparentemente este se encontra localmente (quase como as interfaces remotas do session). Mas na verdade os métodos chamados são executados no lado servidor... Melhorou

GUJ Expert Membro desde: 12/03/2003 11:25:57 Mensagens: 4680 Offline

Ted ... conta pra gente como você fez essa coisa tão bonita @.@

Se voce pensa em garantir uma evolução legal da sua aplicação, para um produto comercial, sugiro:

1 - Front-End - JavaServer Faces

2 - Business-Tier - EJBs (Stateful, Stateless, Entity CMP com CMR e EJB-QL)

3 - EAT - Tier - EJBs (MessageDriven) e JCA (Connectores para Legado)

Dessa forma, idependente do tamanho do cliente (10 a 100k) transações hora, seu sistema terá performance, robutez, escalabilidade e evolutibilidade..

[]'s

Virtual Machine Man Membro desde: 09/05/2003 00:32:03 Mensagens: 607 Offline

Na verdade eu crio um BO normalmente:

Aí eu tenho uma factory para gerar esses Bos para mim, BusinessFactory. Estes meus Bos utilizam (geralmente) um DAO... Para isso eu posso criar uma interface de marcação ou algo parecido (talvez um objeto pai de todos os Bos) para definir quais utilizam DAO e já passar para os mesmos o DAO (no meu caso o dao é genérico utilizando hibernate).

Na parte cliente eu tenho um objeto que é responsável por criar estes mesmos Bos no lado cliente (aqui entra meu primeiro SessionBean). Esse SessionBean cria o Bo através da factory (BusinessFactory) e gera um proxy, o qual é realmente passado para o cliente (nessa parte eu estou utilizando o CGLIB para gerar o proxy). Quando o método é invocado no lado cliente, os dados são passados para o server (meu segundo Session) que realmente executa o método.

Ficou bom de programar e dá para melhorar muito ainda... Usar algum framework para IoC já vai facilitar mais ainda...

É mais ou menos isso... hehehe... Inclusive qualquer crítica é muito bem vinda...

Vallew

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