****************************************************************** * * Ministério da Saúde adverte: Lá vem post gigante * ******************************************************************
Eu gostaria de reforçar a mensagem de que nem o Cairngorm nem o PureMVC vai atender você 100%. Mas é errado usar isto como argumento para não usar Framework algum. Eu sempre tive a impressão que as pessoas que criticam o Cairngorm ou o PureMVC se baseam muito mais nas suas crenças do que em conhecimento de verdade. É como se os programadores que criticam sem conhecimento o fizessem assim por não conhecerem algo que eu gosto de chamar de Conceptual Constraints. Não há problema algum em dois programadores terem soluções distintas. Isto é, de fato, a regra e não a exceção. Agora, o que acontece quando vemos uma determinada solução e pensamos: "eu jamais faria assim"; "esta solução é tão distinta da minha que não consigo ver sentido algum em fazer deste modo". Pior, o que acontece quando não entendemos porque aquela solução que jamais imaginaríamos é a melhor? É aqui que entram as Conceptual Constraints. Definição ======= Conceptual Constraints são conceitos que você mantém na mente e que lhe obrigam a procurar outras alternativas para resolver um problema, pois você sabe que as soluções que lhe ocorreram num primeiro instante irão violar estes conceitos. Basicamente, se dois programadores tem em mente as mesmas Conceptual Constraints, ou seja, se eles sabem principalmente as coisas que eles NÃO DEVEM fazer, isto irá permitir que, no mínimo, um entenda a solução do outro - não descarto a hipótese que estes dois programadores cheguem a soluções semelhantes graças ao fato de ambos saberem o que NÃO DEVE ser feito. Exemplos de Conceptual Constraints do Cairngorm: - O ModelLocator não deve saber nada do Command nem da View - O Command não deve saber nada da View - A View não deve saber nada do Command - O ModelLocator é possível manter o estado no cliente, mas os dados nele armazenados devem ter um significado semântico. No lugar de preço, nome e descrição, devemos ter um objeto Produto no ModelLocator. Além disto, estes objetos, muitas vezes devem encapsular lógica de negócio – o que possibilita a realização de testes unitários - Os Commands são as Worker Classes do Cairngorm. Como tal, elas devem prover a funcionalidade de negócios do seu aplicativo. - Nada impede que o Command tenha apenas um método “execute”. Resumindo o meu post que já está maior do que eu gostaria, o que eu quero dizer simplesmente é que se você entende os conceitos seguidos pelas pessoas que fizeram os Frameworks fica muito mais fácil entender porque eles de fato agregam valor. Por outro lado, se você não conhece as Conceptual Contraints que levaram o Cairngorm e o PureMVC a ser do jeito que eles são, você vai sim achar que eles são ruins, não lhe atendem e que você seria capaz de fazer algo bem melhor (não que não seja desde que você saiba muito bem do que está falando). []'s Beck Novaes On Aug 18, 3:54 pm, "Vicente Maciel Junior" <[EMAIL PROTECTED]> wrote: > Uso Cairngorm e AirCairngorm (desenvolvido pelo Eric Feminella > -http://www.ericfeminella.com/blog/2008/06/22/air-cairngorm-20/). > > Me atende completamente, inclusive na questão dos Modules, que até pra mim > já foi um mito mas que a arquitetura ModelLocator resolve facilmente. > Implementando os módulos dentro do mesmo projeto, não tive problemas. > > Pelo fato do Cairngorm (site do projeto) ter sido movido recentemente do > labs.adobe.com para o opensource.adobe.com, acredito que uma atualização / > novo release ou simplesmente alguma novidade esteja por vir (esperança?). > Sinceramente o que mais me incomodou foi falta de suporte e o atraso em se > ter uma implementação oficial do projeto para atender implementações em AIR > (Business Objects). Inicialmente implementei uma solução própria mas depois > adotei o AirCairngorm que ficou bem mais abstrato do que eu tinha feito na > época do Apollo c/ SQLite. > > Tenho muita curiosidade e vontade de utilizar o PureMVC, mas o tempo me > obriga a só mergulhar em uma alternativa se ela for realmente necessária. > Isso ainda não me ocorreu. Quase ocorreu em relação ao Modules, mas acabou > sendo apenas influência do que eu ja tinha lido a respeito de Cairngorm x > Modules. > > Enfim, acho que a principal característica do Cairngorm você já citou: > Simplicidade. E falo disso sem nem mesmo comparar ao PureMVC, mas que me > parece ser aplicável no contexto de comparação sim. > > Como instrutor, achei muito fácil inclusive ensinar o Cairngorm, enquanto eu > mesmo nas poucas tentativas que fiz de tentar brincar com o PureMVC, senti > uma certa complexidade que não experimentei com o Cairngorm. O legal nesse > ponto é que consigo tranferir o conhecimento para eventuais pessoas que > agrego na equipe de desenvolvimento, com muita facilidade. Esse seria também > um ponto que eu consideraria ao adotar um padrão. E aliás foi o mesmo fator > que me levou a adotar o ColdFusion como plataforma server-side. > > -- > Vicente Maciel Junior > Independent Web Developer & Consultant > Adobe Advanced Certified Developer > Adobe Certified Instructor (ColdFusion & Flash Platform) > +55 (71) 8120-0035 / 9212-0909 - MSN: [EMAIL > PROTECTED]://teclandoalto.blogspot.com > > 2008/8/18 Pergentino Araújo <[EMAIL PROTECTED]> > > > Olá Pessoal, > > > estou estudando estes dois frameworks (PureMVC & Cairngorm), afim de > > analisá-los e definir qual o melhor para utilizar em meu projeto de mestrado > > (específico). > > > Gostaria de opiniões de vocês sobre estes frameworks (preferencialmente > > quem trabalhou/brincou com ambos), pois o que eu vejo na literatura, é que a > > galera opta mais pelo Cairngorm, pelo fato de ser fácil de implementar e > > também de ser da própria adobe, mas parece que o mesmo está paralizado (isto > > é muito ruim). > > > Enfim, é mais pra uma troca de experiência e, quando o trabalho estiver > > concluído, compartilharei com vocês o resultado de minhas análises ;) > > > []'s > > -- > > Atenciosamente, Pergentino. --~--~---------~--~----~------------~-------~--~----~ Você recebeu esta mensagem porque está inscrito na lista "flexdev" Para enviar uma mensagem, envie um e-mail para [email protected] Para sair da lista, envie um email em branco para [EMAIL PROTECTED] Mais opções estão disponíveis em http://groups.google.com/group/flexdev -~----------~----~----~----~------~----~------~--~---
