> Os frameworks são aconselhados para equipes com mais desenvolvedores > (aproveita a padronização do código). E para projetos onde existe > apenas um, ou no máximo dois desenvolvedores, quais diferenças vocês > notaram no uso de frameworks?Quais seriam essas necessidades que ele > preenche?
Bem, as "necessidades que ele preenche" são as necessidades que todo Framework de MVC preenche. Basicamente, Desacoplar a View e isolar a lógica de negócio (se bem que vejo muita gente usando o Cairngorm sem fazer nenhuma coisa nem outra). O grande problema destes FW é que ao resolver alguns problemas potenciais utilizando Design Patterns eles criam outros "problemas". No caso do Cairngorm e do PureMVC o número de classes tende ser grande e isto incomoda muita gente - não acho necessariamente um problema desde que ainda sim seja fácil navegar pelo código. Agora, voltando aos "problemas potenciais", pode ser que devido a inúmero fatores as pessoas nunca venham a ter de fato estes problemas e por não enxergar isto elas acabam modificando os FW para resolver os problemas dos FW. O lado ruim disto é que na maioria das vezes tenho visto que estas modificações jogam por água abaixo os problemas potenciais que os FW tentam resolver. Nestes casos não faz sentido algum utilizar um FW modificado a não ser para ter um padrão de codificação. Outro ponto importante a ser observado é que estes FW não tornam o desenvolvimento mais rápido num primeiro instante. De fato, no início de um projeto eles tornam as coisas muito mais burocráticas. No entanto, conforme o projeto cresce e o tempo passa estes FW provêm excelentes maneiras de adicionar funcionalidades sem destruir o que estava funcionando além do fato de que se você tiver que fazer isto anos mais tarde é provável que se encontre mais facilmente no código devido a padronizacão. Enfim, os FW são um prejuízo no curto prazo visando um benefício a longo prazo. E, respondendo a sua pergunta, mesmo equipes pequenas podem tirar proveito dos FW principalmente se o projeto for grande e for preciso dar manutenção ao longo dos anos. Eu tenho a impressão que muitas pessoas não gostam destes FW porque elas nunca tiveram e talvez nunca tenham encarado os problemas potenciais que eles se propõem a resolver. > Tenho utilizado o Flex com o Spring (devido ao caso que comentei no > inicio da discussão), com ele já consigo fazer essa IOC (no Java).Qual > a diferença de se usar o IOC com o Spring ou com o Swiz? Eles são > complementos, ou fazem o mesmo serviço? Primeiro, respondendo a pergunta, eles fazem o mesmo serviço. Mas por que isto? Pelo mesmo motivo que no Flex você implementa um MVC na camada front-end. O ponto é que a camada front-end no Flex não pode ser confundida com a camada View do MVC. Um front-end Flex é um front- end Rico, é um Rich Cliente e desta forma ele pode ter não só a View mas também o Model e o Controller. Um Front-end Flex tende a ser mais complexo e na medida que a complexidade aumenta você pode lançar mão das mesas soluções e práticas que se aplicam ao back-end. Se você olhar um trecho da definição de IOC extraído da wikipedia: "In practice, Inversion of Control is a style of software construction where reusable, generic code controls the execution of problem- specific code with the strong connotation that the reusable code and the problem-specific code are developed independently and the result often being a single integrated application." Enfim, assumindo que um front-end pode ser complexo e fora a integração ele independe do back-end fica fácil entender que você pode aplicar IOC no front-end também. Att, Beck Novaes --~--~---------~--~----~------------~-------~--~----~ Você recebeu esta mensagem porque está inscrito na lista "flexdev" Para enviar uma mensagem, envie um e-mail para flexdev@googlegroups.com Para sair da lista, envie um email em branco para flexdev-unsubscr...@googlegroups.com Mais opções estão disponíveis em http://groups.google.com/group/flexdev -~----------~----~----~----~------~----~------~--~---
