Introdução ao Doctrine

O Doctrine é uma ferramenta de mapeamento objeto-relacional (ORM) para PHP 5.2.3+. Um de seus principais recursos é a opção de se escrever consultas de bancos de dados em um dialeto SQL proprietário orientado a objetos chamado Doctrine Query Language (DQL), que foi inspirada na Hibernate Query Language (HQL) do framework Hibernate para Java. Isso fornece aos desenvolvedores uma alternativa poderosa ao SQL que mantém a flexibilidade sem duplicações desnecessárias de código.

Os Models gerados pelo Doctrine extendem da classe Doctrine Record, onde todos eles herdam métodos típicos de um Active Record, como os métodos save, delete, etc, além de permitir que o Doctrine participe e monitore o ciclo de vida dos registros. Outros componentes do Doctrine fazem os trabalhos mais pesados, como por exemplo a classe Doctrine_Table. Esta classe possui os métodos típicos de um Data Mapper, como, por exemplo, createQuery, find, findAll, findBy*, etc.

No Doctrine as consultas são baseadas em classes ao invés de tabelas, para demonstrar um exemplo, considere a seguinte consulta:

FROM Usuario
LEFT JOIN u.Enderecos WHERE u.id = 1

Com ela pode-se notar o seguinte:

• É feita uma seleção do Model Usuario e não da tabela;
• É possível referenciar os campos do Model;
• São feitos joins com associações;
• Não existe condição de join, as associações entre as classes e como elas estão no banco de dados são conhecidas pelo Doctrine.

Estas informações foram traduzidas do Manual Oficial do Doctrine, com algumas modificações para clarear o entendimento.

Definição do Projeto com o Zend Framework

Agora que já foi feita uma breve explicação sobre o Doctrine é hora de gerar um projeto de exemplo com o Zend Framework. O projeto criado será bem simples, apenas para exemplificar algumas operações básicas com o Doctrine. Neste ponto presumo que você leitor tenha o Zend Framework e sua ferramenta de linha de comando configurados em seu sistema operacional. Caso não tenha feito isso, recomendo o tutorial do Adler Medrado, onde ele ensina como fazer estas configurações.

O primeiro passo é criar a estrutura do projeto com o comando:

zf create project zf_doctrine

Caso nenhum erro ocorra este comando gerará a seguinte estrutura:

Estrutura básica de um projeto Zend Framework

A pasta application será onde o código específico da aplicação será armazenado. Este código inclui as configurações da aplicação para ambiente de desenvolvimento, produção ou demais ambientes configurados; os Controllers responsáveis por intermediar o fluxo entre as Views, que cuidam da apresentação ao usuário, e os Models responsáveis pela lógica de negócio da aplicação.

A pasta docs é utilizada para armazenar as documentações da aplicação e dos componentes. library é onde ficam armazenados os plugins, componentes e demais bibliotecas de terceiros. Ela é utilizada para armazenar o Doctrine e toda estrutura de classes do Zend Framework. A pasta public é a pasta acessível pelo servidor web, onde é feita toda a chamada para inicializar a aplicação, seguindo o padrão Front Controller. E a pasta testes é onde são armazenados os testes unitários.

Integração

A primeira coisa a se fazer é o download do framework Doctrine. Na data em que este artigo foi escrito a última versão estável do framework é a 1.2.1. Você pode baixá-la neste link. Após ter efetuado o download e extraído o pacote, é necessário copiar todo o conteúdo da pasta lib para a pasta library do projeto Zend Framework criado, resultando na seguinte estrutura:

Estrutura com o Doctrine extraído

Após isso é necessário criar a pasta db e dentro dela as seguintes pastas:

• fixtures – Pasta onde armazenará arquivos de definição de dados para popular o banco de dados;
• migrations – Arquivos de migração entre diferentes versões de banco de dados;
• schema – Definição de toda estrutura do banco de dados, seguindo o formato YAML;
• sql – Armazena a estrutura SQL que define o banco de dados.

Depois de criar estas pastas, também pode ser criada a pasta para armazenar os scripts de linha de comando do Doctrine. Dentro de application é criada uma pasta com o nome de scripts. Após criar todas estas pastas a estrutura será a seguinte:

Estrutura final de diretórios

Após toda a estrutura estar definida é hora de começar a configurar o projeto. A primeira coisa a se fazer é, abrir o arquivo application/configs/application.ini, e acrescentar o seguinte conteúdo nele, na seção [production]:

autoloaderNamespaces[] = "Doctrine"
doctrine.dsn = "mysql://usuario:senha@host/banco"
doctrine.models_path = APPLICATION_PATH "/models"
doctrine.data_fixtures_path = APPLICATION_PATH "/../db/fixtures"
doctrine.migrations_path = APPLICATION_PATH "/../db/migrations"
doctrine.sql_path = APPLICATION_PATH "/../db/sql"
doctrine.yaml_schema_path = APPLICATION_PATH "/../db/schema"
; Conservative Model Loading
doctrine.model_autoloading = 2

Nestas linhas é definido o Namespace utilizado pelo Doctrine para o autoLoader carregar as classes automaticamente, logo em seguida é definido um Nome de Fonte de Dados (Data Source Name – DSN) para a localização do banco de dados, em seguida são definidas as pastas onde são armazenados os models, as fixtures, a sql, e o schema, e, por último é definida a forma como o Doctrine carregará os Models, neste caso é utilizado o Conservative, que carrega os Models conforme eles sejam necessários.

Logo abaixo da linha doctrine.model_autoloading é necessário definir algumas configurações para a ferramenta de linha de comando do Doctrine (Doctrine Cli), basta colocar o seguinte conteúdo:

[doctrineCLI : production]
doctrine.generate_models_options.pearStyle = true
doctrine.generate_models_options.generateTableClasses = false
doctrine.generate_models_options.generateBaseClasses = true
doctrine.generate_models_options.baseClassPrefix = "Base_"
doctrine.generate_models_options.baseClassesDirectory =
doctrine.generate_models_options.classPrefixFiles = false
doctrine.generate_models_options.classPrefix = "Model_"
; Agressive Model Loading
doctrine.model_autoloading = 1

Neste ambiente é necessário configurar as formas como os Models serão gerados. A primeira linha configura a nomenclatura no formato PEAR, onde o nome da classe contém como prefixos a estrutura de diretório onde ela está localizada, por exemplo, Model_Produto, estará na pasta model/Produto.php, no caso da nomenclatura do Zend Framework, a pasta models terá como prefixo Model_, seguindo o padrão do Autoloader do framework. A segunda linha indica ao Doctrine CLI para não gerar as classes Table automaticamente. A terceira linha configura o Doctrine CLI para que gere classes base, onde a quarta linha configura o prefixo das classes Base e a linha seguinte define um diretório vazio, fazendo com que as classes geradas sejam armazenadas no diretório models/base ao invés de models/Model/Base. A próxima linha indica que os nomes de arquivos não devem conter prefixos, a linha seguinte indica ao prefixo das classes geradas, que deverá ser Model_, como explicado. E a última linha define que a forma de carregar os Models será Agressive, ou seja, eles são carregados na inicialização do Doctrine.

Após definir toda essa estrutura é  hora de configurar a inicialização do Zend Framework para que ele carregue e configure corretamente o Doctrine e demais classes necessárias pela aplicação. Para isso, basta abrir o arquivo application/Bootstrap.php, e colocar o seguinte conteúdo nele:

<?php
class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
	protected function _initAutoload()
	{
		$autoloader = new Zend_Application_Module_Autoloader(array(
			'basePath' => APPLICATION_PATH,
			'namespace' => ''
		));
		return $autoloader;
	}
	protected function _initDoctrine()
	{
		$this->getApplication()->getAutoloader()
								->pushAutoloader(array('Doctrine', 'autoload'));
		spl_autoload_register(array('Doctrine', 'modelsAutoload'));

		$doctrineConfig = $this->getOption('doctrine');
		$manager = Doctrine_Manager::getInstance();
		$manager->setAttribute(Doctrine::ATTR_AUTO_ACCESSOR_OVERRIDE, true);
		$manager->setAttribute(
			Doctrine::ATTR_MODEL_LOADING,
			$doctrineConfig['model_autoloading']
		);
		Doctrine::loadModels($doctrineConfig['models_path']);

		$conn = Doctrine_Manager::connection($doctrineConfig['dsn'], 'doctrine');
		$conn->setAttribute(Doctrine::ATTR_USE_NATIVE_ENUM, true);
		return $conn;
	}
}

O primeiro método configura o Autoloader do Zend Framework, para que ele cuide do carregamento das classes necessárias na aplicação. O segundo método configura o Doctrine. Primeiramente ele adiciona o Autoloader do Doctrine ao Autoloader do Zend Framework, permitindo ao Doctrine carregar as classes específicas de seus componentes. A próxima linha configura o Autoloader de Models do Doctrine, para que o Doctrine também cuide do carregamento de seus Models, conforme for necessário na aplicação. As linhas seguintes cuidam de:

• Pegar as configurações definidas no arquivo application.ini;
• Definir os atributos do Doctrine, onde o primeiro atributo definido é a sobrescrita de acessores e o segundo é a forma como os Models são carregados;
• Carregar os Models, conforme a forma definida na linha anterior;
• Gerar uma conexão ao banco de dados, baseada na dsn definida no arquivo de configuração;
• Utilizar a forma nativa de ENUM.

Com isso o arquivo de inicialização do Zend Framework está devidamente configurado. A última etapa é criar a ferramenta de linha de comando do Doctrine. Para fazer isso basta criar o arquivo application/scripts/doctrine.php e colocar o seguinte conteúdo nele:

<?php
//Caminho para a pasta da aplicação
defined('APPLICATION_PATH')
    || define('APPLICATION_PATH', realpath(dirname(__FILE__) . '/..'));
//Ambiente em que a aplicação será executada
defined('APPLICATION_ENV')
    || define('APPLICATION_ENV', (getenv('APPLICATION_ENV') ? getenv('APPLICATION_ENV') : 'doctrineCLI'));

//Adiciona a "library" no include_path
set_include_path(implode(PATH_SEPARATOR, array(
    realpath(APPLICATION_PATH . '/../library'),
    get_include_path()
)));

require_once 'Zend/Application.php';
//Cria a aplicação, faz o bootstrap e a executa
$application = new Zend_Application(
    APPLICATION_ENV,
    APPLICATION_PATH . '/configs/application.ini'
);

$application->getBootstrap()->bootstrap('autoload');
$application->getBootstrap()->bootstrap('doctrine');

$config = $application->getOption('doctrine');

$cli = new Doctrine_Cli($config);
$cli->run($_SERVER['argv']);

Este arquivo irá definir a pasta da aplicação, o ambiente doctrineCLI, para pegar as configurações específicas da ferramenta de linha de comando, conforme definido no arquivo application.ini, adicionar a biblioteca de componentes no include_path, inicializar a aplicação, assim como o Autoload do Zend Framework e o Doctrine, pegar as configurações definidas em application.ini, e, finalmente chamar o Doctrine CLI para cuidar de todo o resto. Por último é necessário criar o arquivo executável responsável por chamar esta ferramenta definida. Para isso basta criar o arquivo application/scripts/doctrine e colocar o seguinte conteúdo nele:

#!/usr/bin/env /usr/bin/php
<?php
chdir(dirname(__FILE__));
include('doctrine.php');

O próximo passo é dar permissão de execução a esse arquivo:

$ chmod a+x zf_doctrine/application/scripts/doctrine

Testando

Antes de mais nada, a primeira coisa a se fazer é testar o cliente de linha de comando. Para isso, em um terminal, execute o seguinte comando:

$ zf_doctrine/application/scripts/doctrine

A saída deste comando deverá ser a seguinte:

Doctrine Command Line Interface

doctrine.php build-all
doctrine.php build-all-load
doctrine.php build-all-reload
doctrine.php compile
doctrine.php create-db
doctrine.php create-tables
doctrine.php dql
doctrine.php drop-db
doctrine.php dump-data
doctrine.php generate-migration
doctrine.php generate-migrations-db
doctrine.php generate-migrations-diff
doctrine.php generate-migrations-models
doctrine.php generate-models-db
doctrine.php generate-models-yaml
doctrine.php generate-sql
doctrine.php generate-yaml-db
doctrine.php generate-yaml-models
doctrine.php load-data
doctrine.php migrate
doctrine.php rebuild-db

Se preferir, adicione esta ferramenta no include_path de sua aplicação, seguindo a mesma idéia explanada pelo Adler Medrado. Caso o comando retorne a saída demonstrada acima, a ferramenta da linha de comando deverá estar funcionando corretamente. Agora é hora de criar um banco de dados chamado carros_doctrine. Após criá-lo, crie o arquivo db/schema/schema.yml, e coloque o seguinte conteúdo nele:

Carro:
  connection: 0
  tableName: carro
  columns:
    id:
      type: integer(4)
      fixed: false
      unsigned: true
      primary: true
      autoincrement: true
    nome:
      type: string(150)
      fixed: false
      unsigned: false
      primary: false
      notnull: true
      autoincrement: false
    cor:
      type: string(150)
      fixed: false
      unsigned: false
      primary: false
      notnull: true
      autoincrement: false

Neste arquivo é feita a definição de uma tabela chamada “Carro” para o banco de dados, onde esta tabela terá as colunas:

• id – Que será um campo do tipo Inteiro, chave primária, não aceitará valores nulos e nem valores negativos (unsigned)  e será um campo auto-incremental;
• nome – Será um campo do tipo String, com o tamanho de 150 caracteres e  que não pode ser nulo;
• cor – Será um campo do tipo String, com o tamanho de 150 caracteres e  que não pode ser nulo.

Após criar o banco e definir este arquivo, basta executar a ferramenta de linha de comando para que ela gere o banco de dados e os Models. Para isso basta executar o seguinte comando:

$ zf_doctrine/application/scripts/doctrine build-all-reload
build-all-reload - Are you sure you wish to drop your databases? (y/n)
y
build-all-reload - Successfully dropped database for connection named 'doctrine'

build-all-reload - Generated models successfully from YAML schema
build-all-reload - Successfully created database for connection named 'doctrine'

build-all-reload - Created tables successfully
build-all-reload - Data was successfully loaded

Após executar este comando basta verificar se a pasta models está devidamente preenchida com o arquivo Carro.php e Base/Carro.php.

Agora, caro queira gerar o SQL da aplicação, basta executar o seguinte comando:

$ zf_doctrine/application/scripts/doctrine generate-sql
generate-sql - Generated SQL successfully for models

Após isso, o arquivo db/sql/schema.sql será criado e conterá a SQL do banco de dados, como o trecho a seguir:

CREATE TABLE carro (
	id INT UNSIGNED AUTO_INCREMENT,
	nome VARCHAR(150) NOT NULL,
	cor VARCHAR(150) NOT NULL,
	PRIMARY KEY(id)
) ENGINE = INNODB;

Agora, o último teste para verificar se tudo está corretamente integrado é fazer algumas chamadas no Controller e verificar se tudo é executado corretamente. Dentro do arquivo application/controllers/IndexController.php, existe o método indexAction(), basta definí-lo como a seguir:

public function indexAction()
{
	$carro = new Model_Carro();
	$carro->nome = "Ferrari";
	$carro->cor = "Vermelha";
	$carro->save();

	$query = new Doctrine_Query();
	$query->from('Model_Carro c');
	$query->orderBy('c.id DESC');
	$this->view->carros = $query->execute();
}

Neste método é criado um novo carro com o nome “Ferrari” e a cor “Vermelha”, e então é inserido este carro no banco de dados. Após isso uma consulta de todos os carros do banco de dados é executada e, então, esta consulta é passada para a View, onde é feita uma listagem destes carros e apresentado ao usuário.

Para fazer esta listagem altere o arquivo application/views/scripts/index/index.phtml e deixe-o com o seguinte conteúdo:

<?php foreach ( $this->carros as $carro ): ?>
<h1>Carro #<?php echo $carro->id; ?></h1>
<p>Nome: <?php echo $carro->nome; ?></p>
<p>Cor: <?php echo $carro->cor; ?></p>
<hr />
<?php endforeach; ?>

Nele é feito um laço para percorrer todos os carros imprimindo os dados de cada um ao usuário. Agora basta ir no browser e acessar o projeto, que o seguinte conteúdo será exibido:

Listagem dos Carros

Caso todo este processo ocorra sem erros o Doctrine está devidamente integrado ao Zend Framework.

Conclusão

O Doctrine é uma ferramenta robusta e consistente para mapeamento objeto relacional, e unindo todas as suas funcionalidades com os componentes do Zend Framework é possível obter uma arquitetura altamente consistente e com ferramentas de alto nível. Apesar de ser uma solução minimalista, a integração se mostra devidamente eficaz, provendo todas as funcionalidades das ferramentas de linha de comando e dos componentes de ambos os frameworks. Existem diversas formas de se integrar o Doctrine com o Zend Framework, esta pode não ser a melhor, porém funciona sem maiores problemas. Logo abaixo coloco alguns links com outras formas de integração assim como o screencast que utilizei como base para elaborar este artigo. Até a próxima.

Código-Fonte

O link abaixo é o pacote com todo o código-fonte do projeto desenvolvido neste artigo, junto com a biblioteca Doctrine.

zf_doctrine.tar

Links Úteis

• Deep Integration between Zend and Doctrine 1.2
• Zend Framework and Doctrine – Part 1
• Autoloading Doctrine and Doctrine entities from Zend Framework
• Zend Framework
• Doctrine

Configurando o XDebug

Antes de ir ao Eclipse, é necessário modificar algumas diretrizes de configuração do XDebug, para isto basta abrir o arquivo de configuração do PHP como root:

sudo gedit /etc/php5/apache2/php.ini

E na seção:

[Zend]
zend_extension="/usr/lib/php5/20060613+lfs/xdebug.so"

Adicionar logo abaixo o seguinte conteúdo:

[xdebug]
xdebug.remote_enable=On
xdebug.remote_host="localhost"
xdebug.remote_port=9000

Após fazer isso, basta verificar se o phpinfo() traz o seguinte resultado:

Resultado da função phpinfo()

Com isso o XDebug está devidamente configurado.

Configurando o Eclipse

A primeira coisa a se fazer no Eclipse é adicionar o executável do PHP. No menu Window -> Preferences existe um menu lateral com o título PHP, ao expandí-lo aparecerá a opção PHP Executables, ao clicar nesta opção aparecerá a seguinte janela:

Janela de executáveis do PHP

Basta então clicar no botão Add e colocar um nome qualquer, informar o caminho do executável (por exemplo, /usr/bin/php) e escolher o tipo do debugger, que é XDebug. O próximo passo é configurar as informações do debugger no Eclipse, para isto basta ir em: PHP -> Debug -> Installed Debuggers, lá existirá uma entrada para o XDebug, basta verificar se a porta é a 9000, e caso não seja clicar em Configure e alterá-la. Após isto basta ir em PHP -> Debug e modificar o PHP Debugger para o XDebug.

Após estas configurações o Debugging do Eclipse já deverá estar funcionando. Caso não esteja, é necessário verificar se o servidor padrão está apontando para a URL correta do Web Server, para isto basta ir em Window -> Preferences -> PHP -> PHP Servers e editar as configurações do servidor padrão.

Exemplo de Debugging

Agora a última etapa é fazer um teste para verificar se tudo está funcionando. Para isso basta criar um projeto PHP, e criar um arquivo chamado teste.php. Dentro deste arquivo é acrescentado o seguinte conteúdo:

<?php
$teste = "ola";
$muaha = array();
for ( $i = 0; $i &lt; 3; $i++ ) {
	$muaha[] = $i;
}
array_shift($muaha);
echo "fim";

Ele é bastante simples, vai criar duas variáveis, fazer um laço para preencher o array, tirar o primeiro elemento do array e imprimir o texto fim. Para executar ele, basta clicar na pequena seta logo à direita do botão de Debug, como apresentado na imagem abaixo, e ir em Debug as -> PHP Web Page.

Botão de Debug no Eclipse

Ele então avisará para abrir a perspectiva de Debug, basta confirmar clicando em Yes e a seguinte tela aparecerá:

Perspectiva de Debug

Pode-se notar que existe uma barra logo à esquerda da numeração das linhas, ao clicar nesta barra será adicionado um breakpoint, que é um ponto de parada na execução do script, o que permite verificar a situação do script até este ponto, como as variáveis alocadas, o conteúdo delas etc. A nível de teste, basta colocar 2 breakpoints, um na linha 4 e outro na linha 8. Após isto basta executar o script, clicando no botão com seta verde, localizado na aba Debug, ele é apresentado na imagem abaixo:

Localização do botão para resumir a execução do script

Logo na primeira parada é possível verificar as variáveis, como o array vazio e a string devidamente preenchida, isto é apresentado na imagem abaixo:

Primeira execução do script

Ao clicar novamente no botão para resumir a execução do script, será feito um dos loops do for definido até que a condição especificada ($i < 3) seja cumprida, ou seja, serão necessários 4 cliques no botão para sair do for . Neste laço é possível verificar que o array vai sendo preenchido, e após sair do loop e parar na linha 8 o array está com apenas 2 elementos devido à função array_shift. As imagens abaixo representam, respectivamente, o fim do loop e a parada na linha 8.

Fim do loop: Array com 3 elementos

Parada na linha 8: Array com 2 elementos

E por último, é exibida a saída da página na tela, e a aba de variáveis é limpa, assim como apresentado na imagem abaixo:

Fim do Debug

Concluindo

O XDebug é uma ferramenta bastante útil para programadores PHP, com ela é possível debugar cada trecho do código para garantir uma maior consistência a ele e (tentar) eliminar bugs. Além de debug ela também fornece a funcionalidade de profiling, que será abordada em um artigo futuro. Até a próxima.

A Aplicação

A aplicação desenvolvida é uma lista de afazeres (todo list), altamente simples, porém tendo ela como base é possível desenvolver futuras aplicações, principalmente por ela possuir muitas das funcionalidades que os sistemas reais possuem. O banco de dados definido para a aplicação é mostrado abaixo.

CREATE DATABASE todo_ci;
USE todo_ci;
CREATE TABLE tasks(
	id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
	title VARCHAR(255) NOT NULL,
	completed BOOLEAN DEFAULT FALSE
)ENGINE=InnoDB;

O banco consiste apenas de uma tabela para armazenar as tarefas, contendo o título da tarefa e se ela foi completada (TRUE) ou não (FALSE). Em um sistema de controle de tarefas um pouco mais completo também existiria uma tabela de usuários, mas foge um pouco do escopo desta aplicação. Para configurar o acesso ao banco na arquitetura, é necessário modificar o arquivo database.php localizado em application/config, alterando os atributos: hostname, username, password, database. Como no seguinte trecho:

$db['default']['hostname'] = "localhost";
$db['default']['username'] = "root";
$db['default']['password'] = "";
$db['default']['database'] = "todo_ci";

Outra coisa a se fazer é configurar no arquivo autoload.php dentro de application/config o carregamento automático dos helpers e bibliotecas utilizadas. Para fazer isso basta alterar as linhas:

$autoload['libraries'] = array();
$autoload['helper'] = array();

para

$autoload['libraries'] = array('form_validation', 'session');
$autoload['helper'] = array('url');

Negócio

Como a arquitetura está bem definida com camadas lógicas para negócio e apresentação, pode-se facilmente separar as duas dividindo o desenvolvimento em duas etapas. Na parte de negócio é necessário fazer toda codificação referente a Facade, DAO e Model.

Camadas referentes ao banco de dados

As camadas Model e DAO, são as referentes ao banco de dados. O Model vai ser a representação de uma entidade do banco de dados como um objeto da aplicação e o Data Access Object (DAO) será o objeto que possuirá operações com o banco, como, por exemplo, operações de salvar e obter registros. Para gerar o Model diretamente pelo Doctrine, tendo o arquivo de configuração apresentado acima devidamente configurado, é necessário gerar o arquivo schema.yml, dentro da pasta application/schema, que define os atributos das entidades do banco, ele possui o seguinte conteúdo:

Tasks:
  columns:
    id:
      primary: true
      autoincrement: true
      type: integer(10)
    title:
      type: string(255)
    completed:
      type: boolean

Então, para gerar a classe basta ir a um terminal, e estando na pasta system/application executar o seguinte comando:

$ php doctrine generate-models-yaml

Ele então gerará os arquivos Tasks.php e BaseTasks.php, contidos, respectivamente, em: application/models e application/models/generated. Estes arquivos possuem os seguintes conteúdos:

abstract class BaseTasks extends Doctrine_Record
{
	public function setTableDefinition()
	{
		$this->setTableName('tasks');
		$this->hasColumn('id', 'integer', 10, array('primary' => true, 'autoincrement' => true, 'type' => 'integer', 'length' => '10'));
		$this->hasColumn('title', 'string', 255, array('type' => 'string', 'length' => '255'));
		$this->hasColumn('completed', 'boolean', null, array('type' => 'boolean'));
	}
}

class Tasks extends BaseTasks
{
}

Com isso o Model está gerado, porém ainda falta o arquivo DAO, basta criar então um arquivo chamado TasksDAO.php na pasta application/models e colocar o seguinte conteúdo nele:

<?php
class TasksDAO
{
}

Bom, após ter tudo gerado é necessário criar os métodos referentes as operações básicas com o banco de dados, que são: Create, Retrieve, Update e Delete, ou o tão famoso CRUD. Todas estas operações estarão localizadas na classe TasksDAO. A operação para se criar uma nova tarefa ou atualizá-la é apresentada no código abaixo:

public function save($data)
{
	if ( !isset($data['id']) || !$tasks = $this->fetch($data['id']) ) {
		$tasks = new Tasks();
	}
	$tasks->merge($data);
	$tasks->save();
}

Apesar do Model a nível de código possuir somente os atributos que o banco de dados possui, graças a ele extender da classe do Doctrine é possível se aproveitar de todos os métodos do framework, o que transforma o Model em um Active Record, possibilitando utilizar diretamente dele o método save. Se um id for passado, é feita uma verificação se este id existe e então, caso exista, a operação será uma atualização de um registro já populado. A parte referente ao procedimento de exclusão de um registro é o apresentado abaixo:

public function delete($id)
{
	$tasks = $this->fetch($id);
	if ( $tasks ) {
		return $tasks->delete();
	}
	return false;
}

O método irá procurar por uma tarefa com o id passado e, caso encontre-a, irá excluí-la. O procedimento para se obter todas as tarefas é:

public function fetchAll()
{
	$query = new Doctrine_Query();
	$query->from('Tasks t');
	$query->orderby('t.id DESC');
	return $query->execute();
}

A partir de uma Doctrine Query ele irá procurar todas as tarefas existentes no banco de dados e retorná-las para as camadas superiores. E, por fim, o procedimento para se obter uma determinada tarefa é:

public function fetch($id)
{
	$task = Doctrine::getTable('Tasks')->find($id);
	if ( $task ) {
		return $task;
	}
	return false;
}

Ele irá obter uma tarefa baseado no id passado para o método e irá retorná-la. Com isso a camada de banco de dados está pronta.

Regra de Negócio

A regra de negócio da aplicação ficará na camada Facade, como explicado anteriormente. Ela conterá métodos que o Controller irá chamar. No caso desta aplicação de exemplo estes procedimentos são simplesmente os referentes a um CRUD, mas em uma aplicação real, regras como, por exemplo, de cálculo de juros, ou de fechamento de um pedido, ficariam nesta camada. Na Facade também será feita toda a validação dos dados vindos do formulário. A Facade criada é um arquivo chamado tasks_facade.php e está localizada na pasta application/facades, ele possui o seguinte conteúdo:

<?php
class TasksFacade extends Facade
{
	public function index()
	{
		$dao = new TasksDAO();
		$tasks = $dao->fetchAll();
		return $tasks;
	}
	public function save()
	{
		$this->form_validation->set_rules('title', 'Title', 'required|max_length[255]|htmlspecialchars');

		if ( $this->form_validation->run() == FALSE ) {
			return false;
		} else {
			$array_data = array();
			$array_data['title'] = $this->form_validation->set_value('title');
			$dao = new TasksDAO();
			$dao->save($array_data);
			return true;
		}
	}
	public function update()
	{
		$this->form_validation->set_rules('id', 'Código', 'required');
		$this->form_validation->set_rules('title', 'Título', 'required|max_length[255]|htmlspecialchars');

		if ( $this->form_validation->run() == FALSE ) {
			return false;
		} else {
			$array_data = array();
			$array_data['id'] = $this->form_validation->set_value('id');
			$array_data['title'] = $this->form_validation->set_value('title');
			$array_data['completed'] = ( isset($_POST['completed']) ) ? true : false;
			$dao = new TasksDAO();
			$dao->save($array_data);
			return true;
		}
	}
	public function get($id)
	{
		$dao = new TasksDAO();
		return $dao->fetch($id);
	}
	public function delete($id)
	{
		$dao = new TasksDAO();
		$dao->delete($id);
		return true;
	}
}

O primeiro método será acessado para fornecer todas as tarefas existentes no banco de dados, ele simplesmente chama a DAO para obter estes dados e retorna para a camada de mais alto nível. Os métodos save e update, serão referentes à inserção de um novo registro e à alteração de um registro já existente; onde eles irão validar os dados enviados pelo formulário e, caso tudo esteja corretamente preenchido, irão chamar a DAO para persistir estes dados em banco. O método get irá chamar a DAO para obter a tarefa em questão, passando-a para a camada de cima. O último método, o delete simplesmente irá excluir a tarefa.

Esta é toda a parte referente a negócio da aplicação, agora a última coisa a se fazer é implementar a camada de mais alto nível.

Camada de mais alto nível

Esta camada é composta pelo Controller e pela View, onde o primeiro é relacionado ao controle de fluxo da aplicação e o segundo à apresentação com o usuário. Primeiramente é necessário criar o controller para as tarefas, o nome do arquivo é tasks_controller.php localizado em application/controllers, ele deverá extender da classe Controller padrão do CodeIgniter, como demonstrado asseguir:

<?php
class TasksController extends Controller
{
	public function TasksController()
	{
		parent::Controller();
		$this->load->library('smartyview');
		$this->load->facade('tasks_facade');
	}
}

Este código declara a classe do Controller em questão e seu construtor já irá carregar a Facade utilizada para processar as regras de negócio. O primeiro método a ser implementado é o referente a listagem das tarefas, ele é demonstrado abaixo:

public function index()
{
	if ( $this->session->flashdata('success') ) {
		$this->smartyview->assign('message', $this->session->flashdata('success'));
	}
	$tasks = $this->tasksfacade->index();
	$this->smartyview->assign_by_ref('tasks', $tasks);
	$this->smartyview->display('tasks/index.tpl');
}

Primeiramente ele verifica se existe alguma mensagem para exibir ao usuário, caso existe ele passa esta mensagem para a View. Posteriormente, ele irá chamar a camada Facade para obter os dados das tarefas e, então passará estas tarefas para a View. Agora que o Controller já está criado, junto com seu método index, é interessante configurar o CodeIgniter para que este Controller seja o principal da aplicação, para isso basta localizar a seguinte linha dentro de application/config/routes.php:

$route['default_controller'] = "welcome";

e mudá-la para:

$route['default_controller'] = "tasks";

Ao acessar a raíz do projeto ele então já chamará a ação index do Controller tasks. Agora é necessário desenvolver o layout da aplicação, dentro da pasta views é necessário criar a pasta geral, e criar os arquivos header.tpl e footer.tpl eles serão o cabeçalho e o rodapé da aplicação. O arquivo header.tpl possui o seguinte código:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
		<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
		<title>Afazeres - Arquitetura CodeIgniter</title>
		<link rel="stylesheet" type="text/css" href="{php}echo base_url(){/php}css/style.css" />
	</head>
	<body>
		<div id="wrapper">
			<div id="header">
				<h1>Lista de Afazeres</h1>
			</div>
			<div id="content">

E o footer.tpl:

			</div>
			<div id="footer">
				<p>Fernando Mantoan.</p>
			</div>
		</div>
	</body>
</html>

Com o layout já definido, é hora de criar as Views referentes ao Controller tasks, estas Views deverão estar dentro da pasta application/views/tasks, o primeiro arquivo criado é referente a listagem das tarefas, ele é o arquivo index.tpl e possui o seguinte conteúdo:

{include file="geral/header.tpl"}
{if $message}
<p class="success">{$message}</p>
{/if}
<p>
	{php}
		echo anchor('tasks/add', 'Nova Tarefa');
	{/php}
</p>
<table>
	<thead>
		<tr>
			<th scope="col">T&iacute;tulo</th>
			<th scope="col">Tarefa Completada?</th>
			<th scope="col" colspan="2"></th>
		</tr>
	</thead>
	<tbody>
		{foreach from=$tasks item=task}
		<tr>
			<td class="title">{$task.title}</td>
			<td>{if $task.completed}Completada{else}N&atilde;o Completada{/if}</td>
			<td class="actions center">
				{php}$task = $this->get_template_vars('task');{/php}
				{php}echo anchor('tasks/edit/' . $task->id, 'Editar');{/php}
				{php}echo anchor('tasks/delete/' . $task->id, 'Excluir', 'onclick="return window.confirm(\'Deseja excluir esta tarefa?\');"');{/php}
			</td>
		</tr>
		{/foreach}
	</tbody>
</table>
{include file="geral/footer.tpl"}

Para utilizar algumas das funções nativas do CodeIgniter, foi necessário utilizar a tag {php} do Smarty, que deixa para o PHP executar o código definido entre os delimitadores. Quem for levar mais para frente a arquitetura poderá integrar estas funções com o Smarty para utilizá-las como Helpers e não ter a necessidade de utilizar as funções como código PHP. Agora que a listagem está funcionando é hora de fazer o cadastro de novas tarefas, para isso é adicionado o seguinte método à classe TasksController:

public function add()
{
	if ( !$this->tasksfacade->save() ) {
		$this->smartyview->display('tasks/add.tpl');
	} else {
		$this->session->set_flashdata('success', 'Tarefa cadastrada!');
		redirect('tasks/index');
	}
}

Ele simplesmente verificará se foi possível salvar um novo registro, caso não exibe o formulário de cadastro, e caso a tarefa tenha sido cadastrada redireciona para a listagem de tarefas passando também uma mensagem de sucess. A View referente a este método é o arquivo add.tpl apresentado abaixo:

{include file="geral/header.tpl"}
<h2>Nova Tarefa</h2>
{php}echo validation_errors('<p class="error">', '</p>'){/php}
{php}echo form_open('tasks/add'){/php}
<div>
	<label for="title">T&iacute;tulo:</label>
	<br />
	<input type="text" name="title" value="{php}set_value('title'){/php}" />
</div>
<div><input type="submit" value="Salvar" /></div>
{php}echo form_close(){/php}
{include file="geral/footer.tpl"}

Novamente é necessária a utilização da tag {php} do Smarty, para aproveitar ao máximo os Helpers do CodeIgniter. Esta tela exibirá erros, caso ocorram, e também, o formulário para cadastro de uma nova tarefa. O próximo método a ser implementado é o de atualização de tarefas, ele é apresentado a seguir:

public function edit($id = null)
{
	if ( is_null($id) || !$task = $this->tasksfacade->get($id) ) {
		redirect('tasks/index');
	}
	if ( !$this->tasksfacade->update() ) {
		$this->smartyview->assign_by_ref('task', $task);
		$this->smartyview->display('tasks/edit.tpl');
	} else {
		$this->session->set_flashdata('success', 'Tarefa atualizada!');
		redirect('tasks/index');
	}
}

Ele basicamente verificará se um id foi ou não passado, e se foi informado um id existente no banco de dados, caso estes requisistos sejam atendidos ele irá mostrar pro usuário o formulário de alteração ou uma mensagem de sucesso na alteração. O formulário de alteração (arquivo edit.tpl) é exibido abaixo:

{include file="geral/header.tpl"}
<h2>Editar Tarefa</h2>
{php}echo validation_errors('<p class="error">', '</p>'){/php}
{php}echo form_open('tasks/edit/' . basename($_SERVER['PHP_SELF'])){/php}
<div>
<input type="hidden" name="id" value="{$task.id}" />
	<label for="title">T&iacute;tulo:</label>
	<br />
	<input type="text" name="title" value="{$task.title}" />
	<br />
	<label>Completada? <input type="checkbox" {if $task.completed}checked="checked"{/if} name="completed" value="1" />
</div>
<div><input type="submit" value="Salvar" /></div>
{php}echo form_close(){/php}
{include file="geral/footer.tpl"}

Novamente para utilizar ao máximo os Helpers do CodeIgniter foram necessários alguns workarounds, este formulário segue a mesma idéia do formulário de cadastro, a diferença é que a URL dele precisa do id da tarefa, assim como um input hidden com este id no formulário, e ele apresenta um checkbox para o usuário informar se a tarefa já foi completada ou não. O último método do Controller necessário para esta aplicação é o referente a exclusão de registros. Este método é apresentado abaixo:

public function delete($id = null)
{
	if ( is_null($id) ) {
		redirect('tasks/index');
	} else {
		$this->tasksfacade->delete($id);
		$this->session->set_flashdata('success', 'Tarefa excluída!');
		redirect('tasks/index');
	}
}

Neste caso não é necessário apresentar nenhuma View. A última coisa a se fazer para esta aplicação é definir alguns estilos CSS, para isto foi criada uma folha de estilos simples para tornar a aplicação um pouco mais bonita, esta folha de estilos deve ser armazenada na raíz do projeto em uma pasta com o nome de css, como, por exemplo em ci_todo/css, e o arquivo desta folha de estilos é style.css:

BODY {
	font-family: Arial, Verdana, Helvetica, sans-serif;
}
A {
	color: #000;
	font-weight: bold;
}
DIV#wrapper {
	left: 50%;
	margin-left: -300px;
	position: relative;
	width: 600px;
}
DIV#header {
	margin: 20px 0 40px 0;
}
DIV#header H1 {
	color: #f60;
	font-size: 32px;
	letter-spacing: -2px;
	margin: 0;
}
DIV#content {
	font-size: 12px;
}
DIV#content TABLE {
	border-collapse: collapse;
	width: 100%;
}
DIV#content TABLE THEAD TR TH, DIV#content TABLE TBODY TR TD {
	text-align: left;
	padding: 9px;
}
DIV#content TABLE THEAD TR TH {
	background: #eee;
}
DIV#content TABLE TR TD.title {
	width: 40%;
}
DIV#content TABLE TR TD.actions {
	width: 18%;
}
DIV#content FORM LABEL {
	cursor: pointer;
}
DIV#content FORM INPUT[type="text"] {
	background: #f6f6f6;
	border: 1px #eee solid;
	font-size: 12px;
	margin-top: 10px;
	padding: 3px;
	width: 99%;
}
DIV#content FORM INPUT[type="submit"] {
	background: #f60;
	border: none;
	color: #fff;
	margin-top: 20px;
	padding: 4px;
}
UL, LI {
	margin: 0;
}
P.error, .errorExplanation LI {
	background-color: #603131;
	border: 1px solid #5c2d2d;
	color: #fff;
	font-weight: bold;
	padding: 10px;
	margin: 0 0 15px 0;
}
P.success {
	background-color: #317b17;
	border: 1px solid #317b17c;
	color: #fff;
	font-weight: bold;
	padding: 10px;
	margin-bottom: 15px;
}
DIV#footer {
	font-size: 9px;
	font-weight: bold;
	margin-top: 80px;
}
.center {
	text-align: center !important;
}

Algumas screenshots deste sistema são apresentadas abaixo:

Fim

Bom, assim concluo toda esta série de artigos referentes a uma Arquitetura de Desenvolvimento de Aplicações com o CodeIgniter, eu sinceramente achava esta solução muito boa na época que a criei, porém após terminar a arquitetura proposta no meu trabalho de conclusão de curso eu fiquei muito mais animado com o Zend Framework e este artigo é o último referente a esta arquitetura com CI, o que pode acontecer é de haver atualizações dos artigos sobre esta arquitetura para melhorar o entendimento e revisar os conceitos apresentados caso necessário. Como já havia dito antes, para quem procura uma solução simples e rápida esta arquitetura com o CI pode ser aplicável, mas existem diversas melhorias a serem feitas, seu uso pode então depender muito da disponibilidade de melhorá-la e do gosto por este framework. Bom, por hoje é só, até mais!

Objetivo Geral

Propor uma arquitetura de desenvolvimento de aplicações em PHP contendo design patterns que forneça uma maior estrutura organizacional, padronização de programação, facilidade de manutenção, menos repetição de código e que evite bad smell (algo errado no código que necessita ser refatorado).

Arquitetura Definida

Diagrama da arquitetura definida

O fluxo definido por esta arquitetura segue o padrão definido pelo Zend Framework e, também, possui algumas customizações para a comunicação entre cada camada. A estrutura base do framework é baseada no pattern Model-View-Controller (MVC), o que divide a aplicação em Model, View e Controller. Na arquitetura, conforme apresentado na Figura acima ainda existem as camadas: Facade, Data Mapper e Table Data Gateway.

Todo o fluxo inicia-se por uma requisição feita por um usuário, o framework definirá qual o Controller requerido, este então será responsável por tratar a requisição e, utilizando o pattern Factory Method, o Controller obtém a Facade ligada ao caso de uso a que ele corresponde e então delega para esta camada o processamento da lógica referente a regra de negócio.

A Facade poderá utilizar um Data Mapper para obter dados do banco de dados, ou para fazer operações a registros do banco. O Data Mapper irá utilizar o Table Data Gateway para efetuar as operações SQL, que é a linguagem compreendida pelo banco de dados. Ele também poderá mapear os dados vindos do Table Data Gateway para objetos Model, que representam em forma de objetos as entidades do banco de dados.

Existe ainda a implementação do Observer e Observable, que fazem parte do design pattern Observer. Uma classe Observable possuirá métodos para se conectar a Observers e para notificar cada um deles. A classe Observer irá fazer um log das operações notificadas pela Observable, gravando este log em banco de dados, no formato JSON, para permitir uma consulta posterior.

Após todo o processamento das camadas inferiores ser concluído, o Controller irá continuar o fluxo da aplicação, exibindo a View para o usuário, que pode conter os dados pegos pelo Data Mapper, ou os formulários definidos pelos componentes Zend_Form para obter dados para algum registro, ou mensagens relevantes para informar ao usuário.

O design pattern Singleton é implementado por diversos componentes do Zend Framework, como, por exemplo, o Zend_Auth que é utilizado na autenticação de usuários. Com este pattern é possível manter os objetos durante a aplicação e por apenas um ponto de entrada. Isto garante a consistência deste objeto, sabendo sempre o que esperar dele.

Aplicação de Exemplo

Para fazer o estudo de caso foi necessário a elaboração de uma aplicação, esta sendo um sistema simples de controle de bibliotecas. Como não era necessário especificar um cliente real, foram criadas algumas regras de negócio que o sistema devia atender e então construí todo o sistema utilizando a arquitetura. A observação que deixo para quem for analisar a aplicação é que a regra de negócio é sim extremamente simples, e acredito que se fosse aplicar a aplicação a uma biblioteca real existiria muita coisa a se trabalhar, porém com ela foi possível demonstrar o uso da arquitetura e o resultado foi bem satisfatório. Os casos de uso criados são demonstrados no diagrama de casos de uso apresentado na Figura abaixo:

Diagrama de Casos de Uso

Conclusões

A principal conclusão apresentada na minha monografia é com relação a manutenibilidade dos sistemas e ciclo de vida. Com uma arquitetura padronizada e altamente reutilizável graças a um ótimo framework e a utilização de design patterns pode-se aumentar bastante o ciclo de vida, principalmente porque desenvolvedores que forem alterar as aplicações já prontas, deverão apenas se familiarizar com os patterns já especificados e reconhecidos mundialmente, e, também, ler a documentação da arquitetura, para saberem onde exatamente alterar as partes necessárias. Os trabalhos futuros são:

• Tornar a arquitetura independente de framework;
• Basear a arquitetura em plugins para facilitar a criação e atualização de funcionalidades de sistemas;
• Escolher entre os design patterns existentes para adicionar ou remover patterns de acordo com a necessidade das aplicações que forem desenvolvidas.

Código-Fonte

O código-fonte com a arquitetura e a aplicação de exemplo poderão ser baixados no link abaixo. Se você tiver melhorias e dicas por favor envie um comentário que ficarei bem agradecido, principalmente se forem coisas construtivas. Bom, é isso, gostaria só de anunciar as boas novas e, também, divulgar esta arquitetura, que ao meu ver ficou muito boa para se trabalhar, e que já estou utilizando em um sistema real…

Código-Fonte da Arquitetura

O primeiro passo é instalar os pacotes necessários para poder instalar o XDebug a partir do repositório de extensões PHP:

sudo apt-get install php5-dev php-pear

Com o PECL pode-se instalar novos pacotes no estilo do apt-get, utilizado para instalar pacotes no sistema operacional. Neste repositório é possível instalar o XDebug, para isso basta o seguinte comando:

sudo pecl install xdebug

Após a extensão ser instalada, é necessário verificar o caminho completo onde ela se encontra, para isso basta digitar o seguinte comando:

find / -name 'xdebug.so' 2> /dev/null

No meu caso o caminho retornado foi:

/usr/lib/php5/20060613+lfs/xdebug.so

Agora, a última etapa é configurar o php.ini:

sudo gedit /etc/php5/apache2/php.ini

E adicionar o seguinte conteúdo no fim do arquivo:

[Zend]
zend_extension="/usr/lib/php5/20060613+lfs/xdebug.so"

Onde o caminho utilizado para o atributo zend_extension deve ser o retornado pelo comando de pesquisa. Após isso basta reiniciar o serviço Apache:

sudo service apache2 restart

E então verificar a saída do phpinfo(), que deverá ter um trecho como este:

phpinfo() com dados do XDebug

Bom, com isto a instalação do XDebug foi um sucesso, para quem quer mais informações sobre o XDebug e os repositórios oficiais do PHP:

• Site oficial do XDebug;
• Site oficial do PEAR;
• Site oficial do PECL.

Como o objetivo deste artigo era só abordar a instalação da extensão acredito que a missão esteja cumprida, em um artigo futuro farei um breve tutorial sobre como debugar os scripts PHP e, também, sobre como funciona a ferramenta de profiling desta extensão.
Para quem acompanhou os artigos sobre a arquitetura de software com CodeIgniter, também falo que em breve colocarei aqui o artigo para desenvolvimento de um sistema visando demonstrar o uso desta arquitetura. Agora o tempo está um pouco menos apertado, poderei me dedicar mais ao blog. Até mais.

Estou em processo de término da monografia, além de estar atuando em alguns projetos, em breve espero colocar mais artigos aqui no blog. Até mais.

O primeiro deles é o site da Academia Planeta Corpo. Este site foi marcado por, principalmente, ter sido o primeiro site desenvolvido utilizando um “framework” próprio, seguindo a dica dada por este post. Nele construimos um CMS onde o cliente pode gerenciar as páginas, comentários, notícias e multimídia. A arquitetura foi elaborada no ano passado e não tínhamos conhecimento ainda de front controller, urls amigáveis e etc, e, devido a conclusão do projeto ser urgente, a arquitetura não foi melhorada. Provavelmente se o CMS for ter continuidade ele será re-escrito utilizando frameworks como CodeIgniter ou Zend Framework e será publicado como um CMS open-source, para ver se o projeto tem futuro ou não. Neste CMS utilizamos o framework de persistência Lumine, escrito pelo ZCE Hugo Ferreira da Silva, conterrâneo de Foz do Iguaçu. Utilizamos também o Smarty, template engine muito robusta escrita em PHP e que ajudou a evitar o espagueti, principalmente pela camada de visão não ter uma linha de código php, apenas template tags do smarty. O cliente deu um feedback muito legal sobre o site e sobre o sistema, e agradecemos a paciência tida pelo mesmo, afinal foi uma longa jornada até aqui.

O segundo site é o site da empresa OGA RÃ SA. Uma multinacional que produz diversos produtos de madeira, utilizando apenas matéria-prima reflorestada, garantindo a continuidade do negócio florestal. Este site foi marcado por ter sido o primeiro site real que criamos utilizando Drupal. Nele foram utilizados módulos como: Views, CCK, i18n, ImageCache, Panels e alguns outros. O resultado final do site foi muito bom e acredito que se não fosse coisas como faculdade, monografia e outros projetos, teríamos concluído-o rapidamente. Agradecemos também a este cliente pela paciência e confiança depositada em nós.

Bom, por enquanto é só, esta semana novamente deixarei o blog parado, tenho que finalizar a monografia e me preparar para outras 2 palestras, em breve volto à ativa com algum artigo novo. Até a próxima!

Então, crie o banco de dados utilizando o arquivo encontrado em db/banco.sql. Após certificar-se de tudo estar pronto basta ir no browser e acessar o cliente na sua URL local, para quem não conhece o Zend Framework é necessário acessar a pasta public para que ele funcione… por exemplo: http://localhost/zf_twitter/public. Então é só cadastrar seu usuário e senha do twitter, logar-se e postar seus twitts, visualizar os últimos twitts de seus amigos, seu perfil e fazer buscas por twitts. Espero que gostem e lembro que é um aplicativo simples, mas quem estiver afim pode extendê-lo sem nenhum problema.

Para baixar o cliente, clique aqui

Até o próximo post.