<br><br><div><span class="gmail_quote">Em 22/04/08, <b class="gmail_sendername">Jorge Augusto Senger</b> <<a href="mailto:jasenger@gmail.com">jasenger@gmail.com</a>> escreveu:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Pessoal,<br> <br> A empresa onde trabalho utiliza um ERP, em Clipper, com cerca de 15<br> anos de idade e a idéia aqui é modernizar a aplicação e implantá-la na<br> web, em uma intranet.<br> <br> Quando comecei aqui, o novo ERP já estava sendo desenvolvido em Perl e<br>
CGI. Porém, como muitos membros da lista - o edenc principalmente - já<br> enfatizaram, o CGI está obsoleto e eu não gostaria de reescrever uma<br> aplicação velha usando uma tecnologia ultrapassada.<br> <br> Claro que a primeira coisa que me vem à cabeça é o Catalyst. Gostaria<br>
de aproveitar que o projeto ainda está no início para usar um<br> framework MVC como o Catalyst, mas ainda não me sinto seguro para<br> tomar esta decisão.<br> <br> Um dos aspectos positivos de utilizar Catalyst aqui e não outro<br>
framework é que grande parte da equipe domina Perl, o que tornaria o<br> aprendizado do framework mais rápido.<br> <br> Gostaria de saber dos mais experientes se o Catalyst é uma boa escolha<br> neste caso.<br> As pessoas de minha equipe têm alguns receios e dúvidas a respeito do<br>
uso de um framework no lugar de CGIs:<br> <br> - Medo da aplicação se tornar engessada e dependente do framework;<br> - Qual seria a diferença de performance da aplicação CGI x Catalyst?;<br> - E se mais tarde o Catalyst sumir do mapa? O que vai acontecer com<br>
minha aplicação?;</blockquote><div><br><span style="font-family: courier new,monospace;">Jorge, eu acredito realmente que o cominho natural é ir para o Catalyst e aqui estão alguns motivos:<br>* Vocês já estão codificando algo em Perl, então neste momento você precisa pergar o que existe em CGI e quebrar em 3 partes, sendo elas :<br>
** banco de dados (Model) e mapear todo o teu banco de dados para DBIx::Class, e isto é relativamente rápido, já que você já tem o banco.<br> ** tirar o que é apresentação e colocar no view, e mesmo que ainda esteja em desenvolvimento pelo designer<br>
** a parte lógica já vai direto para o controle, então as funções já podem ser utilizada diretamente no Catalyst, fazendo apenas as alterações necessária de 'dispatch' para o model/view adequado.<br><br>Então o teu desempenho de programação será excelente. Com relação outros tipos de desempenho, a tendência é ser melhor. Ainda mais que você poderá trabalhar nas partes que realmente sejam um gargalho (banco de dados, apresentação ou algo lógica maluca).<br>
<br>Com relação a longevidade do catalyst, é uma boa pergunta e para ela temos uma excelente reposta. O catalyst é antes de mais nada Perl e opensource, então mesmo que o catalyst morra algun dia, qualquer um que saiba perl poderá dar manutenção. Isto é um ponto importante para qualquer projeto.<br>
<br><br></span></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Para tentar esclarecer estas questões tenho lido algumas fontes na web<br>
e o livro do J. Rockway, mas considero a opinião de vocês muito<br> importante também.<br> <br><br> --<br> Jorge Augusto Senger<br> jasenger (at) <a href="http://gmail.com">gmail.com</a><br> _______________________________________________<br>
Cascavel-pm mailing list<br> <a href="mailto:Cascavel-pm@pm.org">Cascavel-pm@pm.org</a><br> <a href="http://mail.pm.org/mailman/listinfo/cascavel-pm">http://mail.pm.org/mailman/listinfo/cascavel-pm</a><br> </blockquote></div>
<br><br clear="all"><br>-- <br>"o animal satisfeito dorme". - Guimarães Rosa