goncin@wordpress.com:~$ _

Linux, programação e toda sorte de nerdices

Arquivos de tags: active record

O Yii Framework e os “models” (modelos)

Dando seguimento à série de artigos sobre o Yii Framework, desejo compartilhar algumas reflexões acerca dos modelos (models) do padrão de desenvolvimento MVC e de como o Yii Framework implementa o conceito.

Para deixar as coisas mais claras, tomei a liberdade de traduzir a definição de modelo constante deste artigo da Wikipédia de língua inglesa (quase sempre mais completa que a versão lusófona):

O modelo é utilizado para gerenciar informações e notificar os observadores quando a informação é alterada. O modelo é a representação dos dados específica de um negócio, sobre os quais a aplicação trabalha. A lógica de negócio dá significado aos dados brutos (como, por exemplo, determinar se hoje é o dia do aniversário do usuário, ou os totais, impostos e valores de frete para itens de um carrinho de compras). Quando o estado do modelo se altera, este notifica suas visões [views] associadas, de forma que elas possam ser atualizadas.

Várias aplicações usam um mecanismo de armazenamento persistente, como um banco de dados, para guardar os dados. O padrão MVC não menciona especificamente a camada de acesso aos dados, porque se supõe que ela esteja sob o modelo ou encapsulada por este. Modelos não são objetos de acesso a dados; contudo, em aplicações muito simples, com pouca lógica de negócio, não há nenhuma distinção efetiva a se fazer. O Active Record é um padrão de desenvolvimento bem aceito e que une o código da lógica de negócios e o de acesso aos dados – um modelo que sabe como persistir a si mesmo.

Do que foi abordado acima, aprofundemos dois tópicos.

1. O modelo nem sempre está relacionado a um objeto de banco de dados

Isso pode soar estranho, mas basta pensar um pouco para dar razão à assertiva. O ciclo de vida de uma aplicação MVC é, basicamente, coletar dados por intermédio de um formulário (visão, view), filtrá-los segundo as regras de negócio (o que é feito no controlador – controller) e armazená-los para posterior consulta, usando os modelos (models) para tanto.

Há ocasiões, no entanto, em que os dados coletados não precisam ou não devem ser armazenados – eles são necessários apenas em uma etapa intermediária do processamento. Talvez o exemplo mais típico dessa situação sejam os formulários de login, nos quais coletamos um nome de usuário e uma senha, que servem à autenticação/autorização. Depois disso, o nome do usuário (ou seu código, dependendo da lógica implementada) é, no máximo, armazenado num cookie ou num objeto de sessão. Armazenar a senha seria um total contrassenso, por questões de segurança.

O que nos impede, então, de representar os dados de um formulário de login como um modelo? É exatamente isso que o Yii Framework faz. Em todo projeto iniciado com o auxílio da ferramenta de linha de comando yiic, é gerado um modelo chamado LoginForm (na pasta protected/models), cujo conteúdo é o seguinte:

class LoginForm extends CFormModel
{
	public $username;
	public $password;
	public $rememberMe;

	private $_identity;

	/**
	 * Declares the validation rules.
	 * The rules state that username and password are required,
	 * and password needs to be authenticated.
	 */
	public function rules()
	{
		return array(
			// username and password are required
			array('username, password', 'required'),
			// rememberMe needs to be a boolean
			array('rememberMe', 'boolean'),
			// password needs to be authenticated
			array('password', 'authenticate', 'skipOnError'=>true),
		);
	}

	/**
	 * Declares attribute labels.
	 */
	public function attributeLabels()
	{
		return array(
			'rememberMe'=>'Remember me next time',
		);
	}

	/**
	 * Authenticates the password.
	 * This is the 'authenticate' validator as declared in rules().
	 */
	public function authenticate($attribute,$params)
	{
		$this->_identity=new UserIdentity($this->username,$this->password);
		if(!$this->_identity->authenticate())
			$this->addError('password','Incorrect username or password.');
	}

	/**
	 * Logs in the user using the given username and password in the model.
	 * @return boolean whether login is successful
	 */
	public function login()
	{
		if($this->_identity===null)
		{
			$this->_identity=new UserIdentity($this->username,$this->password);
			$this->_identity->authenticate();
		}
		if($this->_identity->errorCode===UserIdentity::ERROR_NONE)
		{
			$duration=$this->rememberMe ? 3600*24*30 : 0; // 30 days
			Yii::app()->user->login($this->_identity,$duration);
			return true;
		}
		else
			return false;
	}
}

A classe CFormModel, na hierarquia do Yii Framework, descende de CModel. Estão ali alguns métodos que costumamos ver nos posts anteriores, como o rules(), que estabelece as regras de validação para os dados, e o attributeLabels(), no qual podemos definir os nomes dos campos na linguagem natural do usuário.

Os dados de login são colhidos e processados, mas nunca armazenados em banco de dados – mesmo porque nem a classe CFormModel, nem sua ancestral, CModel, implementam um método save(). Pelo “jeitão de ser” do Yii Framework, CFormModel deve ser usado toda vez que os dados do formulário não serão armazenados (ao menos diretamente) num banco de dados. Para o trabalho com banco de dados, utilizamos o CActiveRecord.

2. O Active Record reúne em si regras de negócio e código de acesso a dados

O quão chocante lhe parece esta afirmação? Trata-se, é verdade, de uma quebra do paradigma MVC, que preconiza que as regras de negócio devem residir unicamente no controlador (controller). Ponderemos, porém: validação de dados é, em última análise, regra de negócio NOTA MENTAL: escrever um post sobre validação de dados no Yii Framework. E, se esses dados foram ou serão armazenados em banco de dados, a validação precisa obedecer, necessariamente, a definição da estrutura do BD, bem como as características e limitações do SGBD correspondente.

Logo, faz todo o sentido deixar que o próprio modelo verifique se a informação a ser armazenada num campo definido como VARCHAR(100) não ultrapassa esse comprimento. Podemos chamar isso, grosso modo, de forma. O controlador poderia ter-se encarregado de checar essa mesma informação quanto ao aspecto do conteúdo: é um endereço existente? É um nome de pessoa válido? É um município dentro da área de representação da empresa?

Por isso, e para poupar o precioso tempo do desenvolvedor, é que o Yii Framework mantém as regras de validação de dados, quanto à sua forma, no modelo (clique aqui para ver o exemplo de um código de modelo gerado a partir de um objeto de banco de dados), refletindo, sempre que possível, as regras já definidas no BD (tais quais campos requeridos, comprimento máximo, tipo de valor – numérico, alfanumérico, etc.). Tudo isso é implementado estendendo-se a classe CActiveRecord que, por seu turno, também estende CModel.

Concluindo…

O Yii Framework nos leva a repensar o conceito de modelo, desprendendo-o da correlação, julgada muitas vezes  necessária, com um objeto de banco de dados. Com isso, as possibilidades de uso dos modelos ampliam-se, como é o caso do formulário de login anteriormente citado.

O framework também implementa de forma elegante o padrão de desenvolvimento Active Record, encarregando os modelos gerados a partir de estruturas de bancos de dados da validação formal das informações, poupando o desenvolvedor de escrever código para isso 8) .

Para saber mais

  • The Definitive Guide to Yii (em português)
Anúncios

Entendendo as “relations” (relações) do Yii Framework

No post em que apresentei o Yii Framework, demonstrei a capacidade que este possui de gerar o código dos modelos para o padrão de desenvolvimento MVC a partir da estrutura do banco de dados. Hoje vou um passo além, para mostrar que o código gerado reflete não apenas os atributos, mas também as relações (foreign keys) existentes entre as tabelas do BD.

Consideremos, pois, uma estrutura de dados bem simples:

A tabela 'aluno' possui uma chave estrangeira N para 1 em 'escola'

A tabela 'aluno' possui uma chave estrangeira N para 1 em 'escola'

Nessa estrutura hipotética, cada aluno está vinculado a uma escola; por óbvio, uma escola pode possuir zero ou mais alunos. Na UML, esse tipo de relação é denominado dependência, como nos ensina o companheiro #SouDev Edgard Davidson. A partir dessas informações, o Gii (scaffolder do Yii Framework – veja aqui como habilitá-lo no seu projeto) pode gerar o código para os modelos. Desde a versão 1.0.1 do framework, não é mais necessário que as relações provenham das chaves estrangeiras previamente definidas no banco de dados; é possível defini-las em código, editando o corpo do método relations().

Do código gerado para ambos os modelos (Aluno e Escola, que se encontram na árvore do projeto sob protected/models), destaco os seguintes trechos:

<?php
class Aluno extends CActiveRecord
{

  (...)

	/**
	 * @return array relational rules.
	 */
	public function relations()
	{
		// NOTE: you may need to adjust the relation name and the related
		// class name for the relations automatically generated below.
		return array(
			'escola' => array(self::BELONGS_TO, 'Escola', 'cod_escola'),
		);
	}

  (...)

}
<?php
class Escola extends CActiveRecord
{

  (...)

	/**
	 * @return array relational rules.
	 */
	public function relations()
	{
		// NOTE: you may need to adjust the relation name and the related
		// class name for the relations automatically generated below.
		return array(
			'alunos' => array(self::HAS_MANY, 'Aluno', 'cod_escola'),
		);
	}

  (...)

}

O Gii capturou as definições de chaves estrangeiras e estabeleceu as relações entre as tabelas de acordo com aquelas. No caso, um aluno pertence a (self::BELONGS_TO) uma escola, que, por seu turno, tem vários (self::HAS_MANY) alunos.

A partir disso, abre-se uma miríade de possibilidades. Neste cenário, seria comum ter de apresentar, junto com as informações do aluno, o nome da escola no qual este estuda. Poderíamos escrever o seguinte:

<?php
  // Recupera os dados do aluno cujo código é 1000
  $aluno = Aluno::model()->findByPk(1000);

  echo 'Código: ' . $aluno->cod_aluno . '<br />';
  echo 'Nome do aluno: ' . $aluno->nome_aluno . '<br />';
  echo 'Nome da escola: ' . $aluno->escola->nome_escola . '<br />';

Notem (linha 7) que, para obter o nome da escola, não foi preciso instanciar um objeto da classe Escola apenas para que obtivéssemos o nome da escola. Ao invés disso, beneficiamo-nos de uma relação definida no modelo Aluno.

De forma semelhante, a partir de uma instância da classe Escola, seremos capazes de listar todos os alunos vinculados a ela, escrevendo algo como:

<?php
  // Recupera os dados da escola cujo código é 50
  $escola = Escola::model()->findByPk(50);

  // Recupera uma lista de alunos vinculados à escola
  $alunos = $escola->alunos;

  foreach($alunos as $aluno) {
    echo 'Código: ' . $aluno->cod_aluno . '<br />';
    echo 'Nome do aluno: ' . $aluno->nome_aluno . '<br />';
    echo '<hr />';
  }

O código da linha 6 é o bastante para se obter uma lista de alunos vinculados à escola, graças à relação definida na classe Escola.

Em ambos os exemplos, utilizei a técnica chamada lazy loading para recuperar dados relacionados. Há ainda outras formas de se fazer isso, bem como outros tipos de relações além de self::BELONGS_TO e self::HAS_MANY, sobre as quais você pode obter mais informações consultado o Guia Definitivo do Yii Framework.

Um aspecto final a ser salientado é que estivemos utilizando, durante todo o tempo, um outro padrão de desenvolvimento, denominado Active Record. Ele nos permitiu trabalhar com as informações do banco de dados sem lançar mão, em momento algum, da linguagem SQL. O Active Record, por sua vez, é uma das implementações possíveis de ORM (Object-relational mapping) 8) .

%d blogueiros gostam disto: