Conceitos e conhecimentos para começar no Catalyst

Thiago Berlitz Rondon
Publicado em 01/01/2010

Conceitos e conhecimentos para começar no Catalyst.

Este ensaio é uma forma objetiva de explicar os conhecimentos necessários para começar a programar utilizando o elegante framework de programação para web. Este texto tende a não ser exaustivo e nem autoritário em nenhum dos tópicos que será abordado. A missão aqui é provocar a curiosidade de conceitos e "ferramentas" para que você possa aproveitar melhor o Catalyst.

A arquitetura definida para elaboração da sua aplicação é sempre um passo importante na construção. Normalmente misturar o código do controlador , apresentação de interface do usúario, acesso aos dados e a regras de negócio podem gerar várias interdependências, ou seja uma alteração em alguma destas partes pode gerar efeitos colaterais e a manutenção ficar extramamente complexa, para isto é interessante definir uma arquitetura padrão ao desenvolvimento para evitar ao máximo este tipo de dificuldade. O MVC é uma boa arquitetura para reduzir estes problemas e tornar a manutenção do software mais ágil.

O Catalyst é um framework desenhado para trabalhar com o este tipo de modelo, por isto é muito importante o entendimento da abordagem sobre o conceito antes de começar.

	"Podemos enfrentar o nosso problema.
	Podemos organizar os fatos como este que temos
	com ordem e método."

	-- Hercule Poirot (1934)

MVC

"Model-View-Controller" é um modelo para separar as partes do seu aplicativo, basicamente tentando efetuar uma ponte entre o modelo mental humano e ao modelo digital para os computadores. Tradicionalmente, esta questão é resolvida de forma separada em:

  • Aceitar e processar as entradas de dados. (Controller)
  • Processar a informação. (Model)
  • Mostrar os dados. (View)

Veja, este modelo diz quem são estes componentes e como eles interagem de forma simplificada, sugiro fortemente a leitura das referencias deste artigo para melhorar a ótica sobre este cénario.

Existem duas escolas sobre como realmente deve funcionar este trabalho, mas as duas concordam:

  • Existem três objetos envolvidos: Model, View a Controller.
  • Informações quando preciso, normalmente é usado um banco de dados.
  • O objeto view gerencia a apresentação das informações para o usuário.
  • O objeto controlador gerencia o processo da requisição, incluindo autenticação e autorização.
  • As regras de negócio, a especificação do seu aplicativo não deve estar no objeto view.
  • Model não deve realizar nenhuma tarrefa "web".
  • Você deve separar as tarrefas de web e de outros componentes reutilizados em serviços como o 'cron jobs' e etc.

Aqui é que as duas escolas divergem. A escola antiga (popularizada pela linguagem Smalltalk) diz que as regras de negócio estejam no Model, e a nova escola (popularizada pelos novos frameworks de web) no qual acredita que o melhor lugar é no objeto Controlador. Ambos trabalham bem, e cada um tem seus prós e contras. Na realidade, esta escolha fica ao seu critério, como sua mente trabalhar melhor e de acordo com suas preferências. Mas, fica a pergunta: É Melhor pensar em um objeto controlador gerenciado a sua conexão com o banco de dados ou um objeto modelo monitorando o estado dos seus pedidos e dizendo ao manipulador como processar os pedidos ?

Sim, esta é a principal pergunta que você deve responder a si próprio sempre que inicializar uma nova construção utilizando o modelo MVC.

Servidores web

Para executar qualquer aplicativo web, devemos pensar em como vamos servir nossos usuários, iremos discutir algumas estratégias aqui.

O servidor Apache é um dos mais utilizados pelo movimento de software-livre, ele é executado por mais de 60% dos servidores web disponíveis na Internet. Vide http://www.apache.org

Com ele podemos pensar em executar nossa aplicação dos seguintes modos:

CGI

É uma tecnologia que consiste em permitir que o usuário repasse parâmetros para o seu aplicativo e assim gerar páginas dinamicamente.

Porém ela é lenta e requer que o desenvolvedor "faça tudo". Com as novas tecnologias desenvolvidas e utilizadas nos últimos anos ela passou a não ser mais recomendada.

mod_perl

Ele é um módulo opcional do Apache, no qual consiste em embutir o interpretador Perl no servidor, além de prover acesso completo a API do servidor Apache, permitindo escrever códigos que interagem entre as requisições.

FastCGI

FastCGI é um protocolo variante do CGI.

A diferença básica é que os processos no protocolo CGI são executados separadamente, ou seja um "processo para cada requisição", além de que existem outros limitadores no processo como reutilização de conexões ao banco de dados, cache de memória e etc. FastCGI pode utilizar um processo persistente para cada processo que pode manipular muitas conexões em seu ciclo (multiplexing).

Existem variantes da implementação do protocolo FastCGI. Eu vou resumir a questão entre duas implementações em relação ao servidor web Apache. FCGID http://httpd.apache.org/mod_fcgid/ no qual é interessante para servidores compartilhados e o fastcgi http://www.fastcgi.com/ que tem um arquitetura direcionada o servidor dedicado para a aplicação.

Abaixo um exemplo de configuração no servidor web Apache para o fastcgi:

	FastCgiIpcDir /var/tmp
	FastCgiServer /opt/catalyst-app/script/www_fastcgi.pl -processes 3

	
		...
		Alias /static /opt/catalyst-app/root/static
		DocumentRoot /opt/catalyst-app/www/root
		Alias / /opt/catalyst-appwww/script/www_fastcgi.pl/
	




Outros servidores.

Além do conhecido Apache, existem outras soluçõs dependendo da sua necessidade.

O lighttpd é um servidor projetado para otimizar ambientes de alta perfomance. Caso vocé esteja projetando uma aplicação para um número significativo de acessos, recomendo o estudo desta implementação.

Veja também o Nginx, http://nginx.org/.

Template Toolkit

Um sistema de templates possui uma missão simples, o objetivo maior com ele é "marcar" algumas sessões do arquivo (com nome de variáveis por exemplo) e o sistema substituir por seus valores.

Existem algumas soluções dentro do Perl para isto e as mais conhecidas são Template::Toolkit, Mason, HTML::Template e algumas outras. A maioria dos exemplos que você irá encontrar nos documentos espalhados pela rede provavelmente estarão utilizando a Template Toolkit (TT).

Na TT, a template é um arquivo texto que contém diretrizes especiais com demarcações, como por exemplo:

    [% conteúdo para o sistema de template processar %]

Abaixo um pequeno script Perl que utiliza a TT:

    use strict;
    use Template;

    my $file = 'example.tt';
    my $vars = {
        fruit => 'apple',
        colors => [ qw(red yellow green blue) ]
    };

    my $template = Template->new();

    $template->process($file, $vars)
    || die 'Template process failed ', $template->error, "\n";

Agora, um exemplo para demonstrar a utilização das diretrizes da template:

    [% fruit %]

    

    [% IF fruit == 'apple' %]
        Apples are red
    [% END %]




Banco de dados

Tudo o que se refere ao banco de dados, ou seja suas informações estão no objeto "Model".

É uma recomendação utilizar um mapeador de objeto-relacional (ORM) no qual você irá facilitar a programação orientada aos objetos utilizando um banco de dados relacional.

Uma estratégia boa no desenvolvimento do objeto "Model" é representar as tabelas em classes, uma "biblioteca compartilhada" no qual a sua manutenção do código será mais eficiênte.

Utilizando esta técnica você não irá se preocupar com os comandos da linguagem SQL, pois você irá usar uma interface de programação.

Minha recomendação é a leitura de alguns módulos como o DBIx::Class e Rose::DB.

Abaixo um exemplo de utilização do DBIx::Class:

	# Conectar ao banco de dados.
	use MyDB::Schema;
	my $schema = MyDB::Schema->connect($dbi_dsn, $user, $pass, \%dbi_params);i

	# Buscar todos artistas (Tabela) e colocar em uma array.
	my @all_artists = $schema->resultset('Artist')->all;

	# Imprimindo o campo "nome" de todo o resultado.
	foreach $artist (@all_artists) {
		print $artist->name, "\n";
	}

	# Buscando todos os CDs que sao do ano "2000".
	my $millennium_cds_rs = $schema->resultset('CD')->search(
  		{ year => 2000 }
	)

Observe que não foi utilizada a linguagem SQL.

Catalyst

Catalyst é um framework de desenvolvimento web elegante, no qual encoraja o programador a reutilização de código.

Dispatching

O cerne do framework é um sistema de dispatching, ou seja obtendo uma URI ele seleciona o bloco do código a ser executado, esta técnica é muito poderosa.

Recomendo a leitura de um excelente método para o dispatching, 'Chained' (vide Catalyst::DispatchType::Chained).

Por exemplo, você requisitando http://myserver.com/acao, basicamente ele irá te encaminhar para o código responsável pela URI acao.

Solicitar e responder. (Resquest/Response)

Esta abstração é a maneira com a qual a aplicação irá solicitar dados (ex. POST, cabeçalhos, ..) e responder de alguma maneira (ex. HTML, JSON, ...).

Motores (engines)

É oferecido um número de adaptadores para os diversos ambientes, como CGI, mod_perl, FastCGI e etc. Eles que são responsáveis por solicitar e responder aos eventos por uma API, assim são tratados da mesma maneira na construção do aplicativo.

Catalyst-Devel

Catalyst::Devel é um pacote para auxiliar o programador, no qual inclui um servidor para desenvolvimento para facilitar o desenvolvimento.

Conclusão

Catalyst é um sistema que oferece um sistema de dispatching, uma abstração para o ciclo de Request/Response com os motores se utilizando do modelo MVC.

O alvo deste documento é oferecer conhecimento para que você possa entender melhor o modelo e sua arquitetura, além de ferramentas que cercam este poderoso framework.

Referências

AUTHOR

Thiago Rondon , trabalha atualmente na Aware TI. http://www.aware.com.br/

blog comments powered by Disqus