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

Obs: Para acompanhar este artigo é muito interessante que você já tenha feito as outras etapas citadas nos artigos anteriores.

Facade Design Pattern

O pattern arquitetural MVC traz uma forma muito mais consistente de se desenvolver aplicações, dando aos desenvolvedores camadas lógicas destinadas a cada parte que compõe uma aplicação, estas sendo lógica de negócio, apresentação e classes de representação de dados. Porém, existem alguns conceitos no mesmo que podem confundir muitos desenvolvedores, um deles é o de onde colocar regras de negócio? Algumas pessoas fazem isso no Controller, deixando o Model apenas como representação do negócio (objetos com get e set) e outros fazem com que o Model seja representação do negócio unido com as regras da aplicação também (por exemplo, uma lógica de venda), e o Controller fica encarregado apenas de controlar o fluxo entre as camadas. Eu particularmente uso o último conceito, por já ter lido ele em vários livros e também por seguir o conceito thin controller and fat model.

Em uma arquitetura de software não pode existir mal-entendimento de conceitos, senão cada programador faria da maneira que acha mais sensata, fugindo da padronização. Para que isso possa ser evitado, essa arquitetura utiliza um design pattern chamado Facade. O conceito de um Facade é simples, esconder várias linhas de códigos em seus métodos, fornecendo métodos comuns a outras partes da aplicação. Ele será utilizado para conter as regras de negócio, fazendo com que o Controller cuide de controle de fluxo e com que o Model fique apenas encarregado da representação do domínio da aplicação. Mesmo que nessa arquitetura o Model represente os dados do banco de dados e o DAO cuide das operações com o banco, poderia existir problemas de padronização com relação a escolha da camada na hora de se codificar a regra de negócio, este problema pode, então, ser resolvido com a Facade conceituada acima. Com isso a arquitetura teria um conceito de “thin controller, thin model and fat Facade“.

Modificando o Core

A camada Facade é criada diretamente no core do CodeIgniter, esta foi uma abordagem simplificada para se criar esta camada, a melhor abordagem seria utilizar os hooks para que não seja necessário um retrabalho ao atualizar o core do framework, pois tendo codificado direto no core alguns arquivos podem acabar sendo substítuidos necessitando a recodificação da camada. Este aviso é necessário pelo simples fato de ser importante saber que existem melhores alternativas.

Tendo tudo explanado, é hora de criar um arquivo chamado Facade.php, dentro de /system/libraries/, e colocar o seguinte conteúdo nele:

<?php
abstract class Facade
{
	public $_parent_name = '';
	public function Facade()
	{
		$this->_parent_name = ucfirst(get_class($this));
		log_message('debug', "Facade Class Initialized");
	}
	public function _assign_libraries($use_reference = TRUE)
	{
		$CI =& get_instance();
		foreach (array_keys(get_object_vars($CI)) as $key)
		{
			if ( ! isset($this->$key) AND $key != $this->_parent_name)
			{
				// In some cases using references can cause
				// problems so we'll conditionally use them
				if ($use_reference == TRUE)
				{
					$this->$key = NULL; // Needed to prevent reference errors with some configurations
					$this->$key =& $CI->$key;
				}
				else
				{
					$this->$key = $CI->$key;
				}
			}
		}
	}
}

Este código utiliza como base o código do Model.php, classe nativa do CodeIgniter, onde no caso da Facade serão configuradas e carregadas as bibliotecas que existem no Controller para deixá-las disponíveis nesta camada, já que isso será útil, por exemplo, na hora de validar formulários. Como o Model já foi implementado para obter estas bibliotecas, utilizar sua implementação era a melhor abordagem para a Facade, mas outra forma seria herdar da classe Model.

Agora, já existe uma camada Facade como base para extender as Facades específicas, só que ainda é necessário implementar um loader para a Facade. O CodeIgniter fornece métodos para carregar o Model, View e as Libraries. Esse loader funciona da seguinte maneira, pelo comando $this->load->model(‘nomedomodel’), de dentro de um Controller, o Model fica disponível para o Controller. O responsável por esta funcionalidade é o Loader, que pode ser encontrado na pasta /system/libraries/Loader.php. Primeiramente é necessário setar um atributo que conterá as Facades carregadas pelo Loader. A definição dos atributos da classe é a seguinte:

var $_ci_ob_level;
var $_ci_view_path        = '';
var $_ci_is_php5        = FALSE;
var $_ci_is_instance     = FALSE; // Whether we should use $this or $CI =& get_instance()
var $_ci_cached_vars    = array();
var $_ci_classes        = array();
var $_ci_loaded_files    = array();
var $_ci_models            = array();
var $_ci_helpers        = array();
var $_ci_plugins        = array();
var $_ci_varmap            = array('unit_test' => 'unit', 'user_agent' => 'agent');

Adicionando a variável $_ci_facades, que será um array contendo as Facades carregadas, a definição então fica:

var $_ci_ob_level;
var $_ci_view_path		= '';
var $_ci_is_php5		= FALSE;
var $_ci_is_instance 	= FALSE; // Whether we should use $this or $CI =& get_instance()
var $_ci_cached_vars	= array();
var $_ci_classes		= array();
var $_ci_loaded_files	= array();
var $_ci_facades		= array(); // Facade pattern added to the CI
var $_ci_models		= array();
var $_ci_helpers		= array();
var $_ci_plugins		= array();
var $_ci_varmap		= array('unit_test' => 'unit', 'user_agent' => 'agent');

Agora, para implementar a funcionalidade de carregar as Facades, é necessário adicionar, neste mesmo arquivo Loader.php, o seguinte método, que pode ser colocado acima do método database():

function facade($facade, $name = '')
{
	if (is_array($facade))
	{
		foreach($facade as $babe)
		{
			$this->facade($babe);
		}
		return;
	}

	if ($facade == '')
	{
		return;
	}

	// Is the facade in a sub-folder? If so, parse out the filename and path.
	if (strpos($facade, '/') === FALSE)
	{
		$path = '';
	}
	else
	{
		$x = explode('/', $facade);
		$facade = end($x);
		unset($x[count($x)-1]);
		$path = implode('/', $x).'/';
	}

	if ($name == '')
	{
		$name = strtolower(str_replace('_', '', $facade));
	}

	if (in_array($name, $this->_ci_facades, TRUE))
	{
		return;
	}

	$CI =& get_instance();
	if (isset($CI->$name))
	{
		show_error('The facade name you are loading is the name of a resource that is already being used: '.$name);
	}

	$facade = strtolower($facade);

	if ( ! file_exists(APPPATH . 'facades/'. $path . $facade . EXT))
	{
		show_error('Unable to locate the facade you have specified: '.$facade);
	}

	if ( ! class_exists('Facade'))
	{
		load_class('Facade', FALSE);
	}

	require_once(APPPATH . 'facades/'.$path.$facade.EXT);

	$facade = ucfirst(str_replace('_', '', $facade));

	$CI->$name = new $facade();
	$CI->$name->_assign_libraries();

	$this->_ci_facades[] = $name;
}

Este código, basicamente, irá incluir o arquivo da Facade e irá deixá-la disponível através de um atributo do Controller em questão, permitindo desta forma que o Controller acesse os métodos desta Facade.

Testando

Agora, é necessário testar se a camada criada está funcionando corretamente. Primeiramente é necessária a criação da pasta facades dentro de /system/application/. Esta pasta armazenará as Facades que a aplicação necessitará. Apenas para testar a camada basta criar o arquivo /system/application/facades/index_facade.php, e colocar o seguinte conteúdo nele:

<?php
class IndexFacade extends Facade
{
	public function index() { echo 'camada facade acionada'; }
}
?>

Dentro do Controller welcome.php, criado no artigo anterior, basta mudar o construtor e o método index(), para que fique assim:

public function Welcome()
{
	parent::Controller();
	$this->load->library('smartyview');
	$this->load->facade('index_facade');
}
public function index()
{
	$this->indexfacade->index();
	$dao = new TarefasDAO();
	$tarefas = $dao->allData();
	$this->smartyview->assign_by_ref('tarefas', $tarefas);
	$this->smartyview->display('index.tpl');
}

Ao chamar no navegador, deverá exibir a mensagem “camada facade acionada“. Com isso, a camada Facade está corretamente integrada ao CodeIgniter, de uma forma que pode ser considerada nativa, pois ela pode ser carregada e acionada da mesma forma que os Models padrão do framework.

Nomenclatura dos Controllers

Agora, para finalizar a definição da arquitetura, é necessária uma modificação na nomenclatura dos Controllers. Isso é necessário pois o CodeIgniter não obriga o desenvolvedor a seguir uma forma de nomear seus Controllers e isso pode dar brechas para ocorrer erros, como o de definir o mesmo nome para o Controller e para o Model, ou ao se criar um nome próprio para os Controllers, ele ser necessário na URL do browser (por exemplo, se seu Controller é Pessoas_controller, a url ficaria: seuhost.com/index.php/pessoas_controller).

A nomenclatura escolhida para esta arquitetura é a mesma do framework CakePHP, onde os arquivos devem ter o sufixo _controller.php, por exemplo pessoas_controller.php, e o nome das classes deve conter o sufixo Controller, por exemplo PessoasController.

Iniciando as modificações necessárias para se estabelecer esta nomenclatura, é necessário modificar a biblioteca do CodeIgniter Router.php, localizada em /system/libraries/, a função _set_request, possui a seguinte linha:

$this->set_class($segments[0]);

Ela seta a classe para o que vier dos segmentos da URL. É necessário adicionar o sufixo “_controller”, ficando esta linha assim:

$this->set_class($segments[0] . '_controller');

A próxima alteração a ser feita é no método _validate_request, a função completa é a seguinte:

function _validate_request($segments)
{
	// Does the requested controller exist in the root folder?
	if (file_exists(APPPATH.'controllers/'.$segments[0].EXT))
	{
		return $segments;
	}
	// Is the controller in a sub-folder?
	if (is_dir(APPPATH.'controllers/'.$segments[0]))
	{
		// Set the directory and remove it from the segment array
		$this->set_directory($segments[0]);
		$segments = array_slice($segments, 1);
		if (count($segments) > 0)
		{
			// Does the requested controller exist in the sub-folder?
			if ( ! file_exists(APPPATH . 'controllers/' . $this->fetch_directory() . $segments[0] . EXT))
			{
				show_404($this->fetch_directory().$segments[0]);
			}
		}
		else
		{
			$this->set_class($this->default_controller);
			$this->set_method('index');
			// Does the default controller exist in the sub-folder?
			if ( ! file_exists( APPPATH . 'controllers/' . $this->fetch_directory() . $this->default_controller . EXT))
			{
				$this->directory = '';
				return array();
			}
		}
		return $segments;
	}
	// Can't find the requested controller...
	show_404($segments[0]);
}

Alterando-a, ela fica:

function _validate_request($segments)
{
	// Does the requested controller exist in the root folder?
	if (file_exists(APPPATH.'controllers/'.$segments[0] . '_controller' .EXT))
	{
		return $segments;
	}
	// Is the controller in a sub-folder?
	if (is_dir(APPPATH.'controllers/'.$segments[0]))
	{
		// Set the directory and remove it from the segment array
		$this->set_directory($segments[0]);
		$segments = array_slice($segments, 1);
		if (count($segments) > 0)
		{
			// Does the requested controller exist in the sub-folder?
			if ( ! file_exists( APPPATH . 'controllers/' . $this->fetch_directory() . $segments[0] . '_controller' . EXT ))
			{
				show_404($this->fetch_directory().$segments[0]);
			}
		}
		else
		{
			$this->set_class($this->default_controller);
			$this->set_method('index');
			// Does the default controller exist in the sub-folder?
			if ( ! file_exists( APPPATH . 'controllers/' . $this->fetch_directory() . $this->default_controller . EXT ))
			{
				$this->directory = '';
				return array();
			}
		}
		return $segments;
	}
	// Can't find the requested controller...
	show_404($segments[0]);
}

O que é feito, é alterar a forma padrão de se adicionar os Controllers, para que eles contenham o sufixo “_controller” em seus nomes. Agora basta mudar a forma de instanciar os Controllers. No arquivo CodeIgniter.php, localizado em /system/codeigniter/, basta alterar a seguinte linha:

$class  = $RTR->fetch_class();

Para:

$class  = str_replace('_', '', $RTR->fetch_class());

Pronto, agora a nomenclatura dos Controllers está padronizada.

Para testar se as alterações estão funcionando, basta renomear o arquivo welcome.php dentro de /system/application/controllers/, para welcome_controller.php, e dentro dele, modificar a declaração da classe e seu construtor, de:

class Welcome extends Controller
{
	public function Welcome
	{

Para:

class WelcomeController extends Controller
{
	public function WelcomeController
	{

Ao acessar o projeto, se tudo aparecer corretamente, significa que a padronização da nomenclatura foi setada com sucesso. Agora, os controllers requisitados por uma URL, como por exemplo index.php/carros, serão referenciados no arquivo com o sufixo _controller e numa classe com o sufixo Controller, por exemplo carros_controller.php e CarrosController.

Concluindo

Assim concluí-se a definição da arquitetura utilizando o Framework CodeIgniter e alguns Design Patterns. Com isso, já é possível desenvolver as aplicações necessárias para você/sua empresa, de uma forma robusta, dando mais facilidade ao trabalho tanto dos designers quanto dos programadores. A arquitetura possui 5 camadas lógicas para desenvolvimento: Controller, Facade, Model, DAO, View; possui os frameworks: Smarty e Doctrine; e possui uma forma padronizada de se nomear os Controllers.

No próximo artigo demonstrarei os passos necessários para se desenvolver um sistema simples de controle de tarefas, para demonstrar o uso de alguns helpers e os exemplos de cada camada lógica desta arquitetura. Futuramente transformarei esta série de artigos referentes à arquitetura com o CodeIgniter em um ebook e publicarei sob a licença Creative Commons, aqui no meu site.

Ficarei agora um tempo sem postar artigos referentes a esta arquitetura, estou com vários projetos de freelance, além de estar trabalhando em tempo integral na B3, e também tenho que refazer boa parte da fundamentação teórica da minha monografia (pois é, agora que troquei de orientador, eu vi que eu estava no rumo errado) e fazer todo o capítulo de experimento dela (digamos, o capítulo principal da monografia), ou seja, estou sem tempo disponível para escrever o próximo artigo. Colocarei alguns posts rápidos aqui no site, mas diariamente estou no twitter, falando do dia-a-dia, reclamando e etc . Bom, então é isso, até a próxima!

Agora saindo um pouco da teoria, é hora de por a mão na massa e começar a integração do framework. Antes de mais nada é necessário fazer o download da última versão estável do Doctrine, de preferência baixar a “Sandbox”, é possível encontrá-la na página oficial do projeto.

Integrando o Doctrine

A primeira etapa é criar uma pasta chamada doctrine dentro de system/database, do CodeIgniter. Após o download do pacote do Doctrine ser concluído, basta extraí-lo e copiar todo o conteúdo localizado na pasta lib deste pacote para a pasta system/database/doctrine. Agora, esta pasta deve conter uma pasta chamada Doctrine e um script PHP chamado Doctrine.php.

A segunda etapa é configurar algumas propriedades do Doctrine para que ele possa ser carregado e para deixá-lo apto a se conectar com um banco de dados. Dentro do arquivo system/application/config/database.php, basta localizar a linha com o seguinte trecho:

$db['default']['cachedir'] = ""; 

Logo abaixo desta linha, insira o seguinte trecho:

//Configura os dados da fonte de dados, declarados acima
$db['default']['dsn'] = $db['default']['dbdriver'] .
							'://' . $db['default']['username'] .
							':' . $db['default']['password'] .
							'@' . $db['default']['hostname'] .
							'/' . $db['default']['database'];
//Inclui a classe do Doctrine
require_once realpath(dirname(__FILE__) . '/../..') . DIRECTORY_SEPARATOR . 'database/doctrine/Doctrine.php';
//Seta o autoloader de classes
spl_autoload_register(array('Doctrine', 'autoload'));
//Carrega a conexão do Doctrine com a string de DSN configurada e o banco de dados escolhido
Doctrine_Manager::connection($db['default']['dsn'], $db['default']['database']);
//Seta a forma de se carregar os models para o tipo "conservative" ou "lazy initiation"
Doctrine_Manager::getInstance()->setAttribute('model_loading', 'conservative');
//Carrega os modelos para o autoloader
Doctrine::loadModels(realpath(dirname(__FILE__) . '/..') . DIRECTORY_SEPARATOR . 'models');

Este código define um Nome de Fonte de Dados (Data Source Name – DSN), depois inclui a classe Doctrine, configura o autoloader do framework, inicia a conexão com o banco de dados pelo DSN definido e no banco de dados definido neste arquivo de configuração (no trecho $db['default']['database'] = “”), seta para que o carregamento de classes seja “lazy”, ou seja, as classes agregadas são carregadas de acordo com a necessidade e, por último, seta a pasta para o Doctrine procurar por seus Models.

Após definir este trecho de código, deve-se garantir que o index.php da aplicação carregue o arquivo de configuração do banco de dados. Para que isso seja feito, basta entrar no arquivo index.php na raíz do CodeIgniter e modificar suas últimas duas linhas, deixando assim:

require_once APPPATH . 'config/database.php';
require_once BASEPATH . 'codeigniter/CodeIgniter'.EXT;

Configurando a Interface de Linha de Comando

O Doctrine possui uma interface executada em linha de comando que pode auxiliar muito na geração dos models, migrações e etc. É sempre bom deixar esta interface funcionando, em qualquer projeto que utilize o Doctrine. Primeiramente, deve-se criar o arquivo doctrine na pasta system/application, sem extensão nenhuma mesmo, e dar um chmod para que ele possa ser executado (chmod a+x). Este arquivo deve ter o seguinte conteúdo:

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

Agora, é necessário criar o arquivo doctrine.php na pasta system/application e colocar o seguinte conteúdo nele:

<?php
require_once 'config/database.php';
//Configura o Doctrine Cli
$config = array('data_fixtures_path' => dirname(__FILE__) . DIRECTORY_SEPARATOR . '/fixtures',
				'models_path' => dirname(__FILE__) . DIRECTORY_SEPARATOR . '/models',
				'migrations_path' => dirname(__FILE__) . DIRECTORY_SEPARATOR . '/migrations',
				'sql_path' => dirname(__FILE__) . DIRECTORY_SEPARATOR . '/sql',
				'yaml_schema_path' => dirname(__FILE__) . DIRECTORY_SEPARATOR . '/schema');
$cli = new Doctrine_Cli($config);
$cli->run($_SERVER['argv']); ?>

Ele será responsável por configurar cada pasta onde o Cli poderá atuar para realizar suas funcionalidades. A próxima etapa é criar os seguintes diretórios dentro de system/application:

• fixtures
• migrations
• schema
• sql

Agora é necessário setar o banco de dados que a aplicação utilizará, por exemplo, tarefas_ci:

$db['default']['database'] = "tarefas_ci";

Após estes passos estarem concluídos, a interface com a linha de comando deverá estar funcionando. Para testá-la, acesse um terminal e digite os seguintes comandos (para sistemas GNU/Linux), onde “suapasta” corresponde ao endereço físico da pasta da aplicação:

$ cd suapasta/system/application
$ php doctrine

Caso apareça uma mensagem dizendo “No direct script access allowed” será necessário acessar o arquivo database.php no diretório system/application/config e comentar o trecho:

 if ( ! defined('BASEPATH')) exit('No direct script access allowed'); 

Importante: deixe este trecho comentando somente para utilizar o Cli, deixe-o descomentado principalmente no ambiente de produção, por questões de segurança. O resultado de executar o Cli é o seguinte:

Doctrine Command Line Interface
doctrine generate-migrations-models
doctrine create-tables
doctrine migrate
doctrine build-all-load
doctrine dump-data
doctrine dql
doctrine generate-yaml-db
doctrine generate-models-db
doctrine rebuild-db
doctrine create-db
doctrine generate-migrations-diff
doctrine drop-db
doctrine load-data
doctrine generate-migration
doctrine build-all
doctrine generate-yaml-models
doctrine build-all-reload
doctrine compile
doctrine generate-migrations-db
doctrine generate-models-yaml
doctrine generate-sql

Testando a Integração

Após várias etapas é hora de efetuar operações para testar a interface de linha de comando do Doctrine e a integração do mesmo com o CodeIgniter. O banco de dados utilizado nesta etapa é o seguinte:

CREATE DATABASE tarefas_ci;
USE tarefas_ci;
CREATE TABLE `tarefas` (
id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
titulo VARCHAR(200) NOT NULL,
situacao ENUM('A', 'F') DEFAULT 'A'
)ENGINE=InnoDB;

A configuração do banco de dados, encontrada no arquivo database.php da pasta system/application/config, deverá ser algo como o seguinte, onde os atributos hostname, username e password deverão ser configurados de acordo com os dados do banco:

//Host do banco de dados
$db['default']['hostname'] = "localhost";
//Usuário para se conectar com o banco
$db['default']['username'] = "root";
//Senha do usuário do banco de dados
$db['default']['password'] = "";
//Banco de dados a se conectar
$db['default']['database'] = "tarefas_ci";
//Driver de conexão com o banco
$db['default']['dbdriver'] = "mysql";

Primeiramente, é necessário criar o schema para o Doctrine poder gerar os models de acordo com o banco de dados, este arquivo segue o padrão YAML para definição dos dados. Para isso basta criar o arquivo schema.yml na pasta system/application/schema e colocar o seguinte conteúdo nele:

 Tarefas:
  columns:
    id:
      primary: true
      autoincrement: true
      type: integer(10)
    titulo:
      type: string(200)
    situacao:
      type: enum
      length: 2
      values: ['A', 'F']

Agora, basta executar o seguinte comando, para os models serem criados em system/application/models:

$ php doctrine generate-models-yaml
generate-models-yaml - Generated models successfully from YAML schema

Ao verificar o conteúdo da pasta system/application/models, os seguintes arquivos devem estar presentes: Tarefas.php e generated/BaseTarefas.php. O conteúdo destes arquivos são, respectivamente:

abstract class BaseTarefas extends Doctrine_Record
{
	public function setTableDefinition()
	{
		$this->setTableName('tarefas');
		$this->hasColumn('id', 'integer', 10, array('primary' => true, 'autoincrement' => true, 'type' => 'integer', 'length' => '10'));
		$this->hasColumn('titulo', 'string', 200, array('type' => 'string', 'length' => '200'));
		$this->hasColumn('situacao', 'enum', 2, array('type' => 'enum', 'length' => 2, 'values' => array(0 => 'A', 1 => 'F')));
	}
}

class Tarefas extends BaseTarefas
{
}

Agora é necessário criar o arquivo TarefasDAO.php na pasta system/application/models, ele terá o seguinte conteúdo:

<?php
class TarefasDAO
{
	/**
	 * Seleciona as tarefas do banco de dados, retornando um array de objetos
	 * @access public
	 * @return array = Array de objetos Tarefa
	 */
	public function allData()
	{
		$query = new Doctrine_Query();
		$query->from('Tarefas t');
		$query->orderby('t.id DESC');
		return $query->execute();
	}
}
?>

Agora, pode-se carregar alguns dados para a aplicação, para popular o banco e posteriormente fazer algumas consultas. O primeiro passo para fazer isso é criar uma fixture que é utilizado para o Doctrine popular o banco, para isto basta criar o arquivo tarefas.yml na pasta system/application/fixtures e colocar o seguinte conteúdo nele:

Tarefas:
  teste:
    titulo: teste
    situacao: A
  teste2:
    titulo: teste2
    situacao: F

Então basta executar o seguinte comando no terminal:

$ php 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 "tarefas_ci" named "tarefas_ci"
build-all-reload - Generated models successfully from YAML schema
build-all-reload - Successfully created database for connection "tarefas_ci" named "tarefas_ci"
build-all-reload - Created tables successfully
build-all-reload - Data was successfully loaded

Neste ponto o banco está devidamente configurado e possui 2 registros inseridos. Agora basta verificar se o Doctrine foi corretamente integrado no CodeIgniter. No Controller welcome.php localizado na pasta system/application/controllers, coloque o seguinte conteúdo:

<?php
class Welcome extends Controller
{
	public function Welcome()
	{
		parent::Controller();
		$this->load->library('smartyview');
	}
	public function index()
	{
		$dao = new TarefasDAO();
		$tarefas = $dao->allData();
		$this->smartyview->assign_by_ref('tarefas', $tarefas);
		$this->smartyview->display('index.tpl');
	}
}
?>

Nele pega-se a classe DAO, então é executado o método que retorna um array de todas as tarefas ordenadas pelo ID em ordem decrescente, passa-se este array de tarefas para a View e a exibe ao usuário. Agora basta então criar a View, ela ficará localizada na pasta system/application/views com o nome index.tpl, e terá o seguinte conteúdo:

<html>
	<head>
		<title>Arquitetura CI</title>
	</head>
	<body>
		<h1>Lista de Tarefas</h1>
		<ul>
		{foreach from=$tarefas item=tarefa}
		<li>{$tarefa.id}, {$tarefa.titulo} - {if $tarefa.situacao eq 'A'}Aberta{else}Fechada{/if}</li>
		{/foreach}
		</ul>
	</body>
</html>

Aqui é feito um laço no array de objetos de Tarefas retornado pela DAO e a cada iteração é impresso, em um elemento de uma lista desordenada, o ID da tarefa, seu título e a situação, que pode ser Aberta ou Fechada.

Bom, com isso encerro mais um artigo sobre a arquitetura de desenvolvimento de software com CodeIgniter, Smarty e Doctrine. No próximo artigo me focarei em impelementar o padrão Facade no framework CodeIgniter, seguido pela mudança de nomenclatura em algumas camadas e, finalmente, pelo desenvolvimento de um sistema de controle de tarefas. Aguardem, até a próxima.

Na arquitetura proposta, o Smarty estará disponível a partir da variável smartyview dos Controllers, assim é necessária a criação de arquivos para localizar e disponibilizar o Smarty como uma biblioteca do CodeIgniter. O primeiro arquivo a ser criado estará localizado na pasta application/libraries e se chamará smartyview.php. Ele terá o seguinte conteúdo:

<?php
if (!defined('BASEPATH')) die('Acesso direto ao script bloqueado.');
require_once BASEPATH . 'application/libraries/smarty_libs/Smarty.class.php';
/**
* Classe que extende smarty para definir algumas configurações básicas de inicialização
*
* @author Fernando
* @package libraries
*/
class SmartyView extends Smarty
{
	/**
	* Construtor da classe, define a pasta de compilação e a pasta de templates
	*
	* @access public
	* @author Fernando
	* @version 1.0
	*/
	public function SmartyView()
	{
		$this->compile_dir = BASEPATH . "application/views/templates_c";
		$this->template_dir = BASEPATH . "application/views";
		log_message('debug', 'Classe Smarty Inicializada');
	}
}
?>

Esta classe que herda de Smarty, é utilizada apenas a nível de inicialização das variáveis necessárias pelo framework. Ela define a pasta onde os templates compilados serão salvos, a pasta onde os templates (arquivos de View) estão localizados e grava no log do CodeIgniter uma informação de que a classe Smarty foi inicializada. É necessária a criação de uma pasta chamada templates_c dentro de application/views, com permissões 0755, ou 0777.

O segundo arquivo a ser criado é o arquivo de configurações para gerar uma instância da classe e marcá-la como inicializada. O arquivo é o smartyview.php localizado dentro de application/config, o código é o seguinte:

<?php
if (!defined('BASEPATH')) die('Acesso direto ao script bloqueado.');
if (!class_exists('SmartyView'))
{
	require_once APPPATH . 'libraries/smartyview' . EXT;
}
$obj =& get_instance();
$obj->smartyview = new SmartyView();
$obj->ci_is_loaded[] = 'smartyview';
?>

Ele inclui a classe SmartyView, criada anteriormente, pega a instância do objeto atual do CodeIgniter (Controller), armazena uma instância da classe SmartyView na variável smartyview e a marca como instanciada nas variáveis de controle do CodeIgniter. Estes são os passos necessários para que o framework Smarty funcione no CodeIgniter.

Agora para testar se tudo está funcionando, basta ir no controller welcome.php localizado em application/controllers, e colocar o seguinte código nele:

<?php
class Welcome extends Controller
{
	public function Welcome()
	{
		parent::Controller();
		$this->load->library('smartyview');
	}
	public function index()
	{
		$this->smartyview->assign('mensagem', 'Mensagem');
		$this->smartyview->display('index.tpl');
	}
}
?>

Agora é necessário criar o arquivo application/views/index.tpl e colocar o seguinte conteúdo nele:

<html>
	<head>
		<title>Arquitetura CI</title>
	</head>
	<body>
		<h1>{$mensagem}</h1>
	</body>
</html>

Se tudo der certo, basta acessar agora a URL definida na instalação do CodeIgniter, por exemplo http://localhost/codeigniter, e será exibida a mensagem “Mensagem”. Isto indica que o Smarty está funcionando perfeitamente, encerrando assim este artigo. No próximo artigo será feita a integração com o Doctrine, seguindo pela implementação da camada Facade e por algumas mudanças na nomenclatura dos Controllers. Até a próxima.

Design Patterns (Padrões de Projetos)

Baseando-se no livro PHP Profissional, escrito por Alexandre Altair de Melo e Mauricio G. F., página 189, os Design Patterns podem ser definidos como sendo soluções para problemas comuns em diversos cenários no desenvolvimento de software onde cada padrão terá:

• um nome, para que se possa descrever um problema de projeto, suas soluções e consequências em uma ou duas palavras;
• uma descrição do problema, para se saber quando aplicar o padrão;
• uma solução, onde serão descritos os elementos que compõem o projeto, seus relacionamentos, suas responsabilidades e colaborações;
• as consequências como sendo os resultados, vantagens e desvantagens da aplicação do padrão.

Design Patterns escolhidos para a arquitetura

Para a arquitetura proposta, será necessária a aplicação de alguns padrões para se obter uma maior organização de código, separando-se cada coisa em sua devida camada lógica, ganhando maior abstração em cada parte da aplicação. Existem alguns patterns que são fornecidos pelos frameworks escolhidos e outros que deverão ser implementados no CodeIgniter, para que ele ofereça um suporte “nativo” a eles. Os padrões que a arquitetura terá são:

• Model-View-Controller
  • Não especificamente um padrão de projeto e mais um padrão arquitetural, é o padrão que prega a separação entre a regra de negócio (model) e a apresentação dos dados (view) da aplicação. Para que ambas as partes consigam se interligar, existe um controlador de fluxo da aplicação (controller) que será responsável por pegar dados do model e passar para a view, ou passar requisições da view para o model. Na arquitetura, o MVC já é fornecido pelo CodeIgniter e ganhou ainda mais abstração com o Smarty, que fornece uma View completamente sem código PHP. O model pode ser abstraído em 2 partes, uma para DAO e outra para o Model em si (representação dos dados do banco de dados), e as regras de negócio ficarão na camada Facade.
• Facade Pattern
  • Um padrão de projeto bastante comum em aplicações Java e que se tornou bastante útil nessa arquitetura. Um Facade pattern tem como principal objetivo melhorar a legibilidade do código entre camadas, no caso da arquitetura, seria a legibilidade do Controller e do Model, agregando em seus métodos códigos com várias linhas e fornecendo métodos que serão comuns a várias outras partes da aplicação. No caso dessa arquitetura cada controller terá sua própria Facade, essa extendendo de uma Facade abstrata, devendo implementar alguns métodos que serão definidos nela. Essas Facades conterão regras de negócio, deixando o Model e o Controller um pouco mais “limpos” de código.
• Data Access Object
  • O DAO não está entre um dos 23 Design Patterns definidos pela Gang of Four, porém está entre os patterns corporativos mais utilizados em aplicações no geral. O conceito dele é simples, fornecer um objeto onde se tenha apenas métodos de persistência. Na arquitetura o DAO irá trabalhar com o Model gerado pelo Doctrine, contendo métodos de acesso ao banco de dados.

Com os padrões de projetos definidos, no próximo artigo apresentarei as implementações necessárias para tornar cada padrão de projeto o mais integrado possível com o framework CodeIgniter e posteriormente desenvolverei uma aplicação para gestão de tarefas utilizando a arquitetura definida. Até a próxima.

Frameworks Escolhidos

Um framework nada mais é do que uma estrutura de software que contém elementos comuns e não-específicos dos sistemas, componentes como helpers HTML, ferramentas de autenticação e validação e geradores de PDF. Seguindo o conceito de Don’t Repeat Yourself (DRY), que prega o reaproveitamento de estruturas já prontas para se trabalhar, os frameworks se tornaram essenciais nesta arquitetura, e unindo cada um deles pode-se fornecer uma ótima estrutura de trabalho. Estes frameworks escolhidos são:

• CodeIgniter
  • O CodeIgniter foi escolhido para fornecer as camadas MVC e o controle das requisições (front_controller, rotas etc.). Existiam outras escolhas como CakePHP ou ZendFramework, porém acredito que o mais fácil de aprender e o mais fácil de se extender e customizar é o CodeIgniter. A partir dele, algumas customizações foram feitas para manter URLs amigáveis e a View e o Model dele foram modificados, graças aos frameworks descritos abaixo.
• Smarty
  • Smarty é um dos principais e mais robustos frameworks de templates para a linguagem PHP. Ele foi escolhido por conter uma sintaxe limpa e simples para as Views, por fornecer capacidades de cache (o CodeIgniter também provia isso para a View padrão dele) e por não conter uma linha de código PHP em seus templates. A partir de algumas configurações, ele é carregado por todos os Controllers que extenderem a classe “Controller” do CodeIgniter. Equipes que contenham designers ganham muitas vantagens ao utilizar o Smarty, pois eles necessitam apenas aprender a linguagem de template do Smarty, que é muito mais fácil do que o PHP em si, além de fornecer uma independência entre programadores e designers.
• Doctrine
  • Doctrine é um framework para persistência de dados que se utiliza de mapeamento objeto relacional. Ele é o framework para PHP que mais se assemelha ao Hibernate do Java, e possui uma linguagem customizada para consultas, o que eles chamam de Doctrine Query Language (DQL). Existem ótimas soluções para persistência no PHP, como Lumine ou EZPDO, mas o Doctrine foi escolhido por possuir uma comunidade grande e ativa de desenvolvimento e pela robustez e consistência de suas funcionalidades. As classes Models que o Doctrine gera substituem o Model padrão do CodeIgniter.

A partir desses frameworks, o desenvolvimento das aplicações se mostrou mais ágil, prático e organizado, fornecendo com poucas configurações um método de desenvolvimento que pode ser utilizado em diversas aplicações pequenas e médias.

Isso encerra o artigo de hoje, no próximo artigo falarei sobre os Design Patterns que a arquitetura implementa, alguns já disponibilizados pelo CodeIgniter, outros customizados para se conseguir mais organização de código e uma maior abstração entre as camadas. Até mais.