A arquitetura ideal

Se livrem do Struts, só isso já causa uma enorme dor de cabeça e atraso.

Depois disso, tentem mapear quais partes do desenvolvimento estão lentas.

louds:

Se livrem do Struts, só isso já causa uma enorme dor de cabeça e atraso.

Depois disso, tentem mapear quais partes do desenvolvimento estão lentas.

Obrigado por sua opinião , mas será que você poderia me dar mais detalhes sobre a sua opinião.

Se você quer aprender qual seria a melhor solução comece por elndo o POEAA, do Fowler, depois passe por page-Jones e Eric Evans.

Se quer apenas aplicar a melhor solução no seu trabalho contrate um consultor, me parece que faltam alguns conceitos a vocês (POJO não é camada, por exemplo).

Cada projeto pode pedir um tipo de arquitetura diferente.

Aqui na empresa temos alguns aplicativos Web que usam a seguinte arquitetura:

JSP -&gt Struts Action -&gt Business Class (Pojos singleton) -&gt DAO/Hibernate ou em alguns casos Web Services

As camadas se comunicam através de TO, e alguns JavaBeans especificos.
No caso dos JSP´s, usamos somente JSTL.

Essa arquitetura pode parecer bem simples e propositalmente ela é!
A ‘manutenabilidade’ era um requisito não funcional muito forte, pois as aplicações iriam sofrer constante evolução.
Hoje vemos que foi a escolha certa, os novos requisitos funcionais são implementados rapidamente. A performance é excelente.
Nesses aplicativos, a adoção da arquitetura mais simples, porém compacta mostrou-se ideal.

Mas como falei no ínicio, cada projeto é diferente, por isso temos também sistemas com arquiteturas bem complexas: Integração com sistemas legados, EJB´s, etc…

O legal é que os nossos aplicativos ‘light’ conversam numa boa com esses sistemas usando webservices. Assim conseguimos dividir e estruturar bem os aplicativos, temos por exemplo um aplicativo de vendas da area administrativa se comunicando um um sistema ‘barra pesada’ de engenharia da area de produção.

Espero ter ajudado!

Abraços!

Cara utilize uma camada Business Delegate para descoplar o seu Controll do Model

As actions chama o business delegate que apenas delega para o facade, e não tem necessidade de utilizar service, use a inteligência no facade, e dele passe para o DAO

E esse papo de que cada projeto exije uma arquitetura diferente é balela… uma arquitetura bem definida atende a qualquer projeto J2EE

E mais uma coisa que esqueci, só em utilizar um MVC bem estrturado já vai dar trabalho para fazer funcionalidades.

Não se livre do Struts não, se livre do Spring

Struts e Hibernate só

leandroqbs:

E esse papo de que cada projeto exije uma arquitetura diferente é balela… uma arquitetura bem definida atende a qualquer projeto J2EE

agora fiquei curioso.
poderia dar exemplos ou argumentos que justifiquem sua opinião.
não acredito que vc consiga usar a mesma arquiteura em qualquer projeto, isso funciona em projeitnho CRUD que é a mioria dos projetos hj em dia e ach oque é o que vc tem exepriencia.

quanto ao Spring, se vc souber utiliza-lo, com certeza não vai quere tira-lo de seu projeto.

[]'s

Para diversos projetos da empresa na qual trabalhamos, utilizamos a mesma arquitetura… e isso atende muito bem…

é apenas a maior empresa de seguros do país, acha que são projetos CRUD?

Como disse, uma arquitetura bem definida atende a qualquer projeto J2EE.

leandroqbs:

Para diversos projetos da empresa na qual trabalhamos, utilizamos a mesma arquitetura… e isso atende muito bem…

é apenas a maior empresa de seguros do país, acha que são projetos CRUD?

Como disse, uma arquitetura bem definida atende a qualquer projeto J2EE.

ok. Ma se são projetos parecidos(mesma area), então vc não pode dizer que atende a “qualquer” projeto. sempre vai depender do problema. qunato ao que é ser CRUD, se vc mostra dados, faz alguma logica com eles, persiste, consulta, altera, na minha visão é CRUD. o que muda vai so a logica de negocio.

mas vc ão respondeu sobre o Spring. então vou te oerguntar: como vcs fazem controle de transação? na mão? usam um container EJB 2.1?
ou deixam o Spring fazer de forma transparente ao desenvolvedor?
isso so p/ citar uma funcionalidade do Spring.

[]'s

leandroqbs:

E esse papo de que cada projeto exije uma arquitetura diferente é balela… uma arquitetura bem definida atende a qualquer projeto J2EE

Cada projeto não exige uma arquitetura diferente mas não há arquitetura que atenda qualquer projeto. Você está tirando essa conclusão a partir de uma empresa que lida com um tipo de aplicação e em um dominio?

Se tudo que você faz são aplicações web que lidam com XYZ para N usuarios com acesso a internet certamente você consegue reaproveitar muitos dos componentes arquiteturais, mas será que isso é “qualquer projeto J2EE”?

Sua arquitetura suporta SOA? LDAP? CBD? Cluster? RPC? Replicação de Sessão? Uso de scripts? Um milhão de requisições por dia? Segurança configurável? Interface desktop, web e celular? Multiplos bancos de dados usados ao mesmo tempo? Messaging?

Não existe arquitetura que suporte “qualquer projeto J2EE”.

Quanto ao Spring eu realmente estou curioso para que você embase sua afirmação em alguma coisa.

Duvidas:

1 - Pra que Singleton?
2 - Pra que TO?

Cara, a melhor arquitetura sem dúvida é…
“Make it Simple, Make it Better”

Não sai enchendo seu projeto de patterns e frameworks não senão você vai literalmente dar mais corda pra sua forca.

Struts é um framework simples e funcional, spring é muito bom e funciona integrado a qualquer coisa (falo isso pq se ele funciona com vignette, realmente funciona com qualquer coisa ), mas no caso do hibernate e dos patterns, isso que varia muito do contexto do sistema.

Caso uma arquitetura simples não atenda á necessidade, vá alterando sob demanda, até chegar em uma que seja eficiênte e ao mesmo tempo eficaz.

[]´s

O pessoal entende tudo errado, mas beleza…

Lá usamos EJB 2.1 pra controle de transação.

pcalcado:

Raven:

JSP -&gt Struts Action -&gt Business Class (Pojos singleton) -&gt DAO/Hibernate ou em alguns casos Web Services

As camadas se comunicam através de TO, e alguns JavaBeans especificos.
No caso dos JSP´s, usamos somente JSTL.

Duvidas:

1 - Pra que Singleton?
2 - Pra que TO?

Ok Vamos Lá!

1 - Pra que Singleton?

O padrão singleton nos pareceu mais adequando aos objetos de negócios pois realmente eles não precisam ser instanciados várias vezes a cada requisição do mesmo cliente. Poderíamos ter feito inclusive métodos estáticos. Vamos ter apenas um objeto dessas classes em uma interação.

2 - Pra que TO?

Os objetos TO são os objetos de domínio, gerados pelos DAO´s ou também chamados de Transfer Objects ou Value Objects…como queira.

Esses objetos são manipulados pelos business para atender a requisito do negócio.

O Business então devolte ‘Java Beans’ especificos para a View, esses java beans possuem coleções da TO´s, com os dados relevantes.

E claro, existe o processo inverso tb, quando um usuário esta criando ou alterando um objeto do sistema (uma NF, um novo usuário, um item de material), nesse caso os dados são encapsulados em TO´s, (NotaFiscalDTO por exemplo) e esse objeto é persistido, isso claro, após passar a validação.

Entendeu?

Se quiser entrar em mais detalhes fique a vontade!

[ ]´s

leandroqbs:

Cara utilize uma camada Business Delegate para descoplar o seu Controll do Model

As actions chama o business delegate que apenas delega para o facade, e não tem necessidade de utilizar service, use a inteligência no facade, e dele passe para o DAO

Leandro,
sim, consideramos essa hipotese, mas no nosso caso especifico, não foi necessário chegar a esse nível de detalhe. Como falei.

O Action chama direto o obejto de Negocio mesmo.Isso foi uma questão de muita discussão. O Bussines Delegate é sim muito interessante, mas veja só, o acoplamento que existe é só a chamada de um método de negiocio.

De fato que se quisermos, podemos ‘rancar fora o struts’ e tacar ali um Swing ou JSF. O Impacto na camada de negócios é zero.

[]´s

Concordo plenamente com vc nos dois ultimos topicos.

aqui usamos o seu DTO (nosso VO) como um JavaBean, o form popula ele no action…

também não via muita necessidade no Business Delegate antigamente… mas depois de umas sitações que nos deu trabalho sem ele, passei a adotar haahahahahaha

mas é isso aí boa sorte nos projetos

Raven:

pcalcado:

Raven:

JSP -&gt Struts Action -&gt Business Class (Pojos singleton) -&gt DAO/Hibernate ou em alguns casos Web Services

As camadas se comunicam através de TO, e alguns JavaBeans especificos.
No caso dos JSP´s, usamos somente JSTL.

Duvidas:

1 - Pra que Singleton?
2 - Pra que TO?

Ok Vamos Lá!

1 - Pra que Singleton?

O padrão singleton nos pareceu mais adequando aos objetos de negócios pois realmente eles não precisam ser instanciados várias vezes a cada requisição do mesmo cliente. Poderíamos ter feito inclusive métodos estáticos. Vamos ter apenas um objeto dessas classes em uma interação.

2 - Pra que TO?

Os objetos TO são os objetos de domínio, gerados pelos DAO´s ou também chamados de Transfer Objects ou Value Objects…como queira.

Esses objetos são manipulados pelos business para atender a requisito do negócio.

O Business então devolte ‘Java Beans’ especificos para a View, esses java beans possuem coleções da TO´s, com os dados relevantes.

E claro, existe o processo inverso tb, quando um usuário esta criando ou alterando um objeto do sistema (uma NF, um novo usuário, um item de material), nesse caso os dados são encapsulados em TO´s, (NotaFiscalDTO por exemplo) e esse objeto é persistido, isso claro, após passar a validação.

Entendeu?

Se quiser entrar em mais detalhes fique a vontade!

[ ]´s

Mas por que você precisa de TO se você vai mandar mensagens entre objetos que residem dentro de uma mesma JVM? Se prestarem atenção à descrição do padrão Transfer Object no J2EE Design Patterns Catalog (http://java.sun.com/blueprints/patterns/TransferObject.html), vocês vão ler isso:

A menos que você esteja fazendo chamadas a EJBs remotos ou Web Services, não existe necessidade de você ter TOs. Antes que o shoes faça, leia as discussões sobre amenic domain model do GUJ e aos artigos:

• http://fragmental.com.br/wiki/index.php?title=Evitando_VOs_e_BOs
• http://fragmental.com.br/wiki/index.php?title=Fantoches

leandroqbs:

E esse papo de que cada projeto exije uma arquitetura diferente é balela… uma arquitetura bem definida atende a qualquer projeto J2EE

Tenho que discordar…

Se um modelo de arquitetura bem definida serve pra qualquer projeto J2EE, então ele usa TODOS os padrões de projetos? Usa TODAS as APIs do J2EE?

Lógico que não, é por isso que existem várias APIs , que foram criadas para contemplar requisitos diferentes.
Assim como os design patterns.

E os projetos de arquitetura de hardware também serão diferentes em função dos requisitos.

Depende de cada cenário, de cada empresa…

Na empresa onde trabalho, existem sistemas que precisam se comunicar com mainframes, outros que precisam fazer leituras de hardwares específicos…E ainda os sistemas administrativos, aplicações Web ‘comuns’…

Portanto, afirmo que sim, cada sistema exije uma arquitetura diferente! Mas isso não quer dizer que você pode (e até deve) usar a mesma arquitetura em vários projetos, desde que os projetos sejam semelhantes (requisitos semelhantes)

Abraços!

Toda essa diversidade que você citou acontece aqui na empresa…

Uma arquitetura ideal bem definida, diz respeirto as camadas que a aplicação terá e todas as bibliotecas permitidas para uso… dai então vc utiliza a biblioteca (claro q se tiver definida na arquitetura) que precisar…

Uma arquitetura como:

MCV

View: JSP, tags struts e jstl, Tiles (composite view);

Controll: Struts2 (front controller, intercepting filter, dispatcher view e view helper)

desacoplador de camadas: business delegate (service locator);

modelo: EJB 2 ou 3 (session facade, transfer object, data access object, composite entity e application service), se for EJB 2 use Hibernate, se for o 3 use JPA.

Com uma arquitetura nesse perfil, acredito que atenda a qualquer coisa em nível de mercado aqui no RJ. Seja ela pra quaisquer das condições citada no post acima…

se alguem discorda por favor me fala, pois aprendo com tudo isso, e isso é o mais importante aqui

Bom, eu participo de um projeto em que parte da equipe está no RJ e esta arquitetura que você citou não é suficiente. Como você lida com integração com mainframes ou um serviço LDAP, por exemplo? Sua arquitetura ignora integração com outros recursos que não sejam DBMSs, logo sua arquitetura Java EE não é universal, mas focada no universo do domínio que você lida no seu dia-a-dia.

Desculpe só esqueci de citar o “web service broker” no modelo

pra conectar com main frame utilizamos o CICS GATEWAY PROGRAM da IBM.

E isso é utilizado pelo EJB, o que essa arquitetura permite…

Certo, li e entendi…

Nesse caso. Ao invés de eu criar um ClienteDTO só com os dados, eu criaria um Cliente com dados + operações.

Usamos o DTO por uma questão de facilidade, fazemos isso:

O struts retorna para a view apenas os DTO´s, sem operações nenhuma.

Da outra forma, seria assim:

A opção pela primeira forma foi uma decisão de projeto, que nos pareceu ser a melhor na época.

Até o momento, não tivemos problemas sérios com essa arquitetura. Ela esta atendendo bem e inclusive as manutenções evolutivas estão ocorrendo dentro do tempo planejado.

Eu sei que esse tipo de discussão vai longe…

Mas o fato é que os DTO´s estão dando conta do recado!!

Abraços!

Entendi, mas acho que isso ae é mais como um padrão, uma metodologia de desenvolvimento, nesse caso, vc por exemplo teria a disposição uma gama de libs que o fornecedor da sua implementação J2EE oferece.

Mas como falei, imagina só que um projeto qualquer vai exigir a biblioteca J2EE A, ja outro pode exigir também a lib A + B,C e D…

Daí, as arquiteturas vão ser diferentes entre os dois projetos.

No seu caso, você esta definindo a arquitetura como uma lista de componentes que vc pode usar ou não nos projetos. Mas só pode usar os
componentes daquela lista.

Ufa! Acho que é isso!
Abraços

Mais uma vez concordo plenamente com voce… aqui usamos ele mesmo em projetos que não tenha EJB remoto, só pela facilidade de tranferencia de dados entre as camadas da aplicação

Cara… nada pessoal mas é impossível de aceitar sua afirmação de que uma Arquitetura bem definida pode atender QUALQUER projeto JEE

Eu ja trabalhei no rio em um projeto onde a interface era mensagem SMS, com gateways logicos JAVA (Sockets) que transformavam pacotes(bytes) vindos de uma operadora de celular em um post HTTP que caia em um struts modificado que respondia via JMS para otros gateways que convertiam as mesagens JMS em pacotes quee voltavam para a operadora…

só um exemplo…

É claro que uma boa arquitetura pode atender MUITOS projetos JEE, principalmente se forem CRUDS mas não atendem TODO tipo de aplicação JEE…

Muitas coisas ao mesmo tempo, então vou devagar:

1 - Sobre Singletons:

Singletons são utilizados quando é permitido a um objeto ter apenas uma (ou N, depende da interpretação) objetos. Não parece ser o seu caso, me aprece que seus objetos podem ser instanciados mais de uma vez sem que causem problemas.

1.1 - Sobre limitar o número de objetos como ganho de performance

As JVMs trabalham com espaços de memória otimizados apra objetos de vida curta. Não costuma haver ganho real em manter um objeto sem estado (como acredito que os seus sejam) em memória para ganho de performance. Aidna que existe, isso é algo que deve ser medido antes de implementado, Don Knuth já avisa: premature optimization is de root of all evil".

1.2 - Variáveis Globais
Se ainda assim você acha melhor mantêr apenas uma instância de um dado objeto é extremamente ruim que você o acesse via MeuObjeto.getInstance(). Isso simplesmente deixa seu código sem a menor chance de ser testado automaticamente e eleva o acoplamento entre o objeto que chama e o Singleton.

Isso tudo além de praticamente remover a capacidade de usar objetos polimórficos já que ao invés do objeto receber uma instância de outro (que pode ser uma instância de uma subclasse) ele obtêm a instância diretamente (logo nunca pode ser uma subclasse).

Neste caso Singletons são utilizados como variáveis globais e nós temos problemas com variáveis globais desde a programação estruturada.

Isso acontece porque o Singleton não é feito para este tipo de coisa. Quem controla a instanciação de um objeto (e logo se ele não pode ser isntanciado duas vezes) deve ser a Factory. O Singleton é um tipo de objeto especial cuja utilidade só existe em pouquíssimos sistemas.

http://www.c2.com/cgi/wiki?SingletonsAreEvil
http://www.c2.com/cgi/wiki?JavaSingletonProblems
http://www.c2.com/cgi/wiki?AnotherJavaSingletonProblem

2 - Transfer Objects / Data Transfer Objects / Value Objects (da Sun)

Outro problema de usar o padrão em lugar inapropriado.

TO/DTO existe para transmitir dados de um lugar para outro, como descrito por Fowler:

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

Eles só fazem sentido quando precisamos transformar o bojetod e alguma forma para ser enviado. geralmente esta transformação visa reduzir chamadas remotas ao objeto mas pode (no caso de Entity Beans do EJB 2.1, por exemplo) eliminar uma série de limitações com a paltaforma.

Se você não está num cenário onde existem várias JVM se comunicando ou com Entity Beans 2.x provavelmente não há a menor necessidade de uso de TO.

COmo mostrado no artigo que o DQO linkou, usar VO/BO é uma prática que deixa seu sistema completamente procedural, com dados (VO/TO/DTO) separados de lógica (BO). A OO visa exatamente juntá-los em um componente único: o objeto.

3 - Arquitetura Única

Uma arquitetura é guaida pelos requisitos funcionais e não funcionais de um sistema. A menos que estejamos lidando com sistemas muito próximos não há como ter uma arquitetura única.

A arquitetura sugerida não contempla todos os casos (aliás, poucos dos) que questionei, então acredito que temos claramente que ela não é aplicável a “qualquer projeto J2EE”. Há, e desenvolvo aplicações no RJ há quase dez anos e todos os exemplos foram tirados de projetos reais.

Novamente: pode se aplicar a qualquer projeto no seu domínio, na sua empresa mas não a todos. Aidna dentro de uma empresa só já vi mais de uma dezena de vezes uma empresa ter que jogar suas ‘arquiteturas de referência’ no lixo ao perceber que ela fora criada para algo e não era viável em todos os cenários.

Pode dar um exemplo de onde e como usaríamos um singleton devidamente? Se possível, com um snippet.

Pode dar um exemplo de onde e como usaríamos um singleton devidamente? Se possível, com um snippet.

Ate hoje, eu nunca consegui pensar num exemplo sequer onde um Singleton realmente faca sentido. E eu ja tentei bastante.

Pode dar um exemplo de onde e como usaríamos um singleton devidamente? Se possível, com um snippet.

Ate hoje, eu nunca consegui pensar num exemplo sequer onde um Singleton realmente faca sentido. E eu ja tentei bastante.

Perguntei exatamente por que eu também já pensei um bocado nisso e fiquei na mesma que você.