Dessa maneira os Models (DBIx::Class,ElasticSearch,etc) ficam dentro do módulo e não ficam no framework, mesmo sendo possível usar normalmente diretamente no framework, mas talvez esse não seja o conceito de framework agnostic.
No web framework fica a parte web mesmo, mas mais Controllers(thin) e Views e quase nada de Models(pois tudo fica no módulo da app). Assim se eu quero testar a mesma app em 3 webframeworks, preciso apenas alterar a parte do web framework em si ex. urls de entrada, lógica de urls e views. Embora muita coisa pode ser reaproveitada. abs, Hernan On 7/23/13, Hernan Lopes <[email protected]> wrote: > Na dúvida e na certeza entre catalyst, mojo ou dancer, prefiro > desenvolver novas aplicacões como um 'modulo' independente, ou seja, > desacopladas de framework e até da web... em outras palavras: como um > modulo normal para uso via cli/terminal/outras-app. Obviamente com > testes no módulo, e outros no framework web. > > E com o módulo da minha app em mãos, eu consigo adicionar uma camada > web, ex catalyst, mojo, dancer... e fazer: > > use My::Cool::App; > > my $app = etc... > > junto com as urls acessando $app->whatever > > assim fica mais fácil mudar e testar diferentes frameworks > > abs, > > Hernan > > On 7/23/13, Nelson Ferraz <[email protected]> wrote: >>>>> Esse argumento de ser "fácil" e "rápido" é o mesmo argumento que o >>>>> pessoal >>>>> do PHP usa, e no final pela linguagem não ter uma série de features os >>>>> códigos acabam se tornando obscuros por mais que o programador use >>>>> Design >>>>> Patterns. >>>> >>>> Eu conheço mais projetos web bem-sucedidos que começaram com PHP do >>>> que em Java: Twitter e Facebook, para citar dois casos. >>> >>> Sua visão está voltada para quantas teclas você aperta no ciclo >>> inicial do desenvolvimento, e não no ciclo inteiro do software. Como >>> eu já disse antes, usamos o Catalyst por produtividade a curto, médio >>> e longo prazo. >> >> Eu volto a citar alguns dos projetos mais bem sucedidos do mundo: >> Twitter e Facebook, que começaram em PHP. E posso falar em primeira >> mão da Booking.com, que foi inteiramente desenvolvida em Perl. >> >> Em todos estes casos as "melhores práticas" estiveram sujeitas a um >> imperativo maior: getting things done! >> >> No ano passado eu participei do Amsterdam Startup Weekend. O principal >> objetivo do evento é desenvolver, em apenas três dias, um MVP -- >> Minimum Viable Product -- que possa ser testado no mercado. >> >> Sem esta visão pragmática uma pode investir meses em um protótipo que >> no final das contas vai ser jogado fora. >> >> A nossa equipe começou com uma idéia que se mostrou inviável, e no >> segundo dia decidimos começar um novo projeto do zero (o que eles >> chamam de "pivoting"). Por causa disso ganhamos o prêmio especial (ok, >> inventado na hora pelos organizadores :D) de "Spirit of the Startup >> Weekend". >> >> Para concluir... >> >> Não estou dizendo que você deve escrever código ruim. O que eu defendo >> é um equilíbrio entre "melhores práticas" e "produtividade". >> >> Se você consegue ser ágil com Catalyst, ótimo. Mas eu vejo muita gente >> perdendo semanas para conseguir entender uma linguagem ou framework, >> quando podiam estar lançando o protótipo da aplicação em dois ou três >> dias. >> >> PS: você já leu os livros de Kent Back sobre Extreme programming? >> Recomendo!!! >> >> Extreme Programming Explained: Embrace Change >> http://www.amazon.com/Extreme-Programming-Explained-Embrace-Edition/dp/0321278658 >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: [email protected] >> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> >> =end disclaimer >> > =begin disclaimer Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ SaoPaulo-pm mailing list: [email protected] L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer
