Padrões J2EE com Struts

JavaGuru Membro desde: 22/02/2005 19:46:49 Mensagens: 205 Offline

Com base nesse link abaixo, pude pegar todos padrões envolvidos na J2EE.
http://java.sun.com/blueprints/patterns/catalog.html

Eu comecei a fazer uma associação desses padrões com componentes
encontrados no Struts e alguns eu simplesmente associei a padrões que
eu utilizarei num projeto q estou participando.

Gostaria q opinassem sobre.

Business Delegate -> Seria o BO(Business Object)?
Composite Entity -> O Model?
Composite View -> Tiles do Struts?
Data Access Object -> DAO, dahn!!! ^^
Fast Lane Reader -> Não faço a menor idéia
Front Controller -> ActionServlet do Struts, certo?
Intercepting Filter -> Validator do Struts?
Model-View-Controller -> MVC propriamente dito. Ou seja, o próprio Struts.
Service Locator -> Completem por favor.
Session Facade -> Seria a utilizaçao do Padrão Facade mesmo??
Transfer Object -> DTO ou VO certo?
Value List Handler -> Não faço a menor idéia denovo.
View Helper -> Form do Struts, né?

bom, a intenção é q cada um poste a sua versao pra essa lista acima, onde se encontram os Padrões J2EE e Componentes do Struts respectivamente.

Desde já agradeço a atenção de todos,

Opinem!!

Bem, no proprio link que você mandou há os blue prints da Sun explicando de forma geral o que é cada um. É ler e entender mesmo.

Eu posso te indicar dois links no meu próprio site, que mostram na prática o uso do ServiceLocator e da Facade aplicados à componentes de negócio (EJB 3.0).

Aqui:
http://www.fabriciobraga.com.br/?p=10
http://www.fabriciobraga.com.br/?page_id=4

No mais, sugiro que você procure utilizar as J2EE Patterns com parcimônia e evite impregnar seus sistemas com elas se realmente não forem lhe trazer um ganho.

Durante o desenvolvimento do sistema, espere primeiro encontrar o problema, para depois resolve-lo com a Pattern. Pode parecer óbvio, mas não é. Há um número grande de Analistas que ficam catando espaços no modelo para encaixarem as Patterns, para depois encherem a boca enumerando as Patterns que usaram.

Pareço estar exagerando? Veja por si mesmo...

Espero ter ajudado.

[]s
Fabricio Braga
SCJP 1.5
http://www.fabriciobraga.com.br

fabriciobraga wrote:
No mais, sugiro que você procure utilizar as J2EE Patterns com parcimônia e evite impregnar seus sistemas com elas se realmente não forem lhe trazer um ganho.

Durante o desenvolvimento do sistema, espere primeiro encontrar o problema, para depois resolve-lo com a Pattern. Pode parecer óbvio, mas não é. Há um número grande de Analistas que ficam catando espaços no modelo para encaixarem as Patterns, para depois encherem a boca enumerando as Patterns que usaram.

Pareço estar exagerando? Veja por si mesmo...

Espero ter ajudado.

É verdade. No caso, falando do Service Locator e do Façade, entre outros, como o colega estava comentando, são patterns que são mais usados com EJB, embora o façade possa ser usado sem problemas fora do escopo de EJB.
Se não me engano, acho que foi o shoes que falou que alguns dos padrões da Sun foram criados para contornar problemas com EJB.

O padrão Intercepting Filter não é implementado nativamente no Struts, mas pode-se usar Servlet Filters mesmo. Frameworks mais modernos como Mentawai e WebWork implementam esse padrão.

JavaGuru Membro desde: 22/02/2005 19:46:49 Mensagens: 205 Offline

Oia, vc ta certíssimo Fabricio, aqui mesmo nos estamos eliminando padroes na medida q descobrimos q nosso sistema nao sera tao grande a ponto de usá-los. Mas só com o decorrer do projeto é q será possível ver a necessidade de acrescentar outros.
Obriado Microfilo, eu tinha pensado q o validator do struts tinha a ver com esse tal intercept filter. Depois vou analisar os frameworks citados por vc com mais calma.

Vlw mesmo pessoal. Mas alguem sabe do tal "fast lane reader"?

Na minha humilde opinião o Struts em si é fortemente acoplado (principalmente quando se trata do model) o que sugerem a inclusão desses diversos Design Patterns para evitar esse acoplamento. O Struts em si pratica poucos patterns como por exemplo o Command Pattern (que inclusive não foi citado), Front Controller(Action Servlets), Business Logic (Action), Dispatcher e Adpater.

Por um lado, ele é flexível a ponto de permitir a inclusão de outras tecnologias presentes no mercado como o Tiles (composite view), hibernate (Persistência - aqui você aproveita e insere o DAO) e assim vai.

De certa forma, essa acaba sendo uma grande desvantagem do struts. Veja bem, Você resolve utilizar hibernate então você vai ter de criar as classes POJOs das suas entidades. Só que os FormBeans acabam sendo praticamente uma VO o que de certa forma você vai ter de encapsular seus POJOs dentro dos FormBeans gerando uma carga excessiva de duplicação de código.

Além disso, o Struts e limitado ao MVC, permite pouco reaproveitamento (importante caso sua equipe queira mudar de framework um dia), dificuldades de manutenção (se você alterar um FormBean vai ter de Alterar o POJO encapsulado), duplicação de código e dificuldade de fazer testes.

Até

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