… A comunidade em volta da JCP adotou a aberração proposta pela SUN chamada EJB e o mecanismo de persistência seria uma JSR especialista chamada JDO. JDO seria a solução deifnitiva onde não importaria se você usa um txt, um xml ou um Banco de dados parrudo.
Com esse modelo de desenvolvimento foi criado um catálogo de Design Patterns[?] que serviria de “tábua dos 10 mandamentos” para a comunidade. Nasceu a prova de certificação em Arquiteto java com base nessa arquitetura.
Por fora da JCP uma turma se dedicou a criar uma forma de persistência especÃfica para bancos de dados relacionais [Hibernate] onde não estavam preocupados se você guardava seus dados em um xml, queriam apenas resolver os problemas clássicos do mapeamento objeto-relacional. Outro pessoal jogava fora o modelo EJB e criava sua própria JEE [Spring] com técnicas e abordagens que surgiam como IoC, DI, Aspect Programming.
Com esse modelo de desenvolvimento, baseado sobretudo no conjunto de Design Patterns [PoEAA] da turma do Fowler, aposentaram o modelo da SUN apreciado pelos membros da JCP e redirecionaram o comitê para a aprovação de especificações copiadas desse outro modelo.
… and they lived happily ever after.
…
Opa, faltaram atualizar a prova de Arquiteto Enterprisey para adequar aos Patterns corretos. Ainda leio na ementa da prova no capÃtulo sobre Patterns:
- From a list, select the most appropriate pattern for a given scenario. Patterns are limited to those documented in the book – Alur, Crupi and Malks (2003). Core J2EE Patterns: Best Practices and Design Strategies 2nd Edition and named using the names given in that book.
- From a list, select the most appropriate pattern for a given scenario. Patterns are limited to those documented in the book – Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software and are named using the names given in that book.
- From a list, select the benefits and drawbacks of a pattern drawn from the book – Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software.
- From a list, select the benefits and drawbacks of a specified Core J2EE pattern drawn from the book – Alur, Crupi and Malks (2003). Core J2EE Patterns: Best Practices and Design Strategies 2nd Edition.
Categories: Certificações, Design Patterns, Engenharia de Software, Java, JSE, Melhores práticas ~ ~ Trackback
October 28th, 2008 at 4:02 am
Vixe, nem me fale! Se eu estivesse atualmente lendo o PEAA em vez de ser obrigado a ler o Core J2EE Patterns, eu estaria muito mais feliz.
Tô bem decepcionado com essa prova de arquiteto, a parada é chata demais, e pelo que vi, definitivamente não diz se o cara é um bom arquiteto ou um bom memorizador de patterns.
Não vejo a hora de me livrar dessa prova.
October 28th, 2008 at 7:53 am
Hoje sou completamente desacreditado com a certificação de arquiteto (SCEA), mesmo conhecendo alguns bons e maus arquitetos.
Mas enfim, o mercado muitas vezes exige tal certificação como prova de conhecimento [eca!] e algumas vezes não se tem muito para onde correr
)
October 28th, 2008 at 1:39 pm
Hoje sou completamente desacreditado com qualquer certificação…
October 30th, 2008 at 8:46 pm
Oi, Milfont, tudo bom?
Você conhece o Java BluePrints Solutions Catalog for Java EE 5.https://blueprints.dev.java.net/bpcatalog/ee5/index.html? O que me diz sobre eles?
Abraços,
October 31st, 2008 at 9:53 am
Oi Alan, eu considero os blueprints bem confusos, patterns não tão importantes tem relevância e as cerejas do bolo ficaram fora, não há explicação do que são Entities, Value Objects, Services, Repositories, etc.
December 17th, 2008 at 7:37 pm
Mas Milfont, esses patterns que vc falou já estão muito bem documentados no livro do Evans. Vc acha mesmo que deveriam estar em um catálogo Java EE?