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?
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
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.
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:
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…
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.
[quote=“pcalcado”]EJBs são uma dor de cabeça muito grande e não valem a pena. Para uma boa leitura crítica:
Qualquer busco no Google traz muitos artigos sobre as limtiações da arquitetura, e seu porblemas.[/quote]
Vou dar uma pesquisada nisso agora, pra poder opinar melhor.
[quote=“pcalcado”]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[/quote]
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.
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’…
Boa
[quote=“Rafael Nunes”]
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.[/quote]
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.
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 :lol: !!
[quote=“pcalcado”]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).
[/quote]
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.
[quote=“pcalcado”]
O Spring é porreta, mesmo se não for usar agora, leia sobre ele.
[]s[/quote]
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
[quote=“TedLoprao”] 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 :lol: !!
Fallow[/quote]
Não entendi esta parte de executar a funções no servidor por um proxy.
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.
[quote=“Rafael Nunes”]
Não entendi esta parte de executar a funções no servidor por um proxy.
Grato.[/quote]
É 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 :?: :?: :lol:
public class XxxBo {
public void fazAlgo() {
}
}
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…
