<div class="gmail_quote">Em 21 de agosto de 2012 11:04, Jose Nilton <span dir="ltr"><<a href="mailto:jniltinho@gmail.com" target="_blank">jniltinho@gmail.com</a>></span> escreveu:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Obrigado a todos pela ajuda o Leonardo, o Renato pela paciência.<br></blockquote><div>Disponha!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Vou usar esse e-mail para um tutorial, pois o Catalyst as vezes parece muito complicado, mas complicado é a nossa cabeça,<br>
</blockquote><div>Vale lembrar que suas dúvidas estiveram, em geral, centradas em como usar a DBIx::Class ou um ORM em geral, mas o que me chamou a atenção é que você parecia querer usar um ORM como um DAO —por exemplo criando métodos que faziam uma consulta redigida em SQL e que retornavam uma grande massa de dados.</div>
<div><br></div><div>Um ORM vai lhe atender bem «ocultando» de você o SQL, de fato, mesmo quando você precisar de consultas avançadas, você usa SQL::Abstract para construí-las. Acho que vale entender conceitualmente o que é um DAO e o que é um ORM para decidir quando aplicar um pattern ou outro. Isso não só é independente de framework quanto de linguagem.</div>
<div><br></div><div>Pessoalmente eu tenho mais experiência em enviar JS «pronto» para o browser e não em enviar os «dados» para o browser. Eu não estou dizendo que o que eu faço é mais correto. Provavelmente é mais «old school» e eu esteja «perdendo o bonde» aqui, por isso não me leve a mal quando eu acho muito estranho enviar TODOS os registros de uma tabela qualquer para o navegador.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">No Catalyst a gente tem que pensar simples que o Framework faz o resto.</blockquote></div>