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.
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!!
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.
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…
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.
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.
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.
