Padrões J2EE com Struts

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

É 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.

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é