CRUD com PHP OO e MVC Parte 1

Quelipe · Março 28, 2011

Bom, tentei postar este tutorial no imaster como artigo, mas recusaram, pois , disseram que era muito básico, então estarei postando aqui para toda a comunidade.

Aprenderemos neste tutorial que será divido em 4 partes, como criar um CRUD usando o PHP-OO com MySQL em arquitetura MVC.

Para muitos o MVC no PHP somente é possível com a utilização de um framework, então nesse tutorial não iremos utilizar nenhum framework.

Vamos começar o mini curso com a INCLUSÃO (INSERT) de registros em um banco de dados e essa primeira parte será a base para as outras 3 (DELETE, UPDATE e SELECT).

Primeiramente vamos criar uma pequena base de dados para fazermos nossos testes, essa base no nosso caso chama-se crud, neste banco criaremos uma tabela chamada cadastro, contendo os seguintes campos: id_cadastro, nome, idade e telefone. Para facilitar segue abaixo o SQL:

CREATE TABLE  `crud`.`cadastro` (
 `id_cadastro` int(10) unsigned NOT NULL AUTO_INCREMENT,
 `nome` varchar(45) NOT NULL,
 `idade` int(10) unsigned NOT NULL,
 `telefone` varchar(12) NOT NULL,
 PRIMARY KEY (`id_cadastro`)
) ENGINE=InnoDB AUTO_INCREMENT=12 DEFAULT CHARSET=latin1;

Após criado o bando de dados e a tabela, vamos para a estrutura de diretórios onde ficarão os arquivos do nosso CRUD.

Criaremos as seguintes pastas:

/view

/controller

/model

Na camada visão (ou pasta view) ficarão todos os nossos arquivos de interação do nosso CRUD, como: formulários de cadastros, listas entre outros.

Na camada controle (ou pasta controller) ficarão todos os nossos arquivos de intermediação entre a camada de visão e persistência do nosso CRUD, nessa camada que serão feitas todas as validações do CRUD.

Na camada de persistência (ou pasta model) ficarão todos os arquivos que fazem interação diretamente com o banco de dados.

Fora de todas as camadas irá ficar o arquivo que contém o menu do sistema, nesse tutorial terá apenas o link de inclusão.

Como é um arquivo bem simples segue o código:

<html>
<title>CRUD PHP OO Modelo MVC</title>
</head>

<body>
<input type="button" onClick="document.location='view/cad_cadastro.php'" value="Novo"><br />
</body>
</html>

No código acima colocamos um botão que dará acesso à pagina cad_cadastro.php que se encontra dentro da camada de visão (view), salve-o com o nome menu.php

Feito isso, vamos para a segunda parte do sistema, criar a visão que será o arquivo cad_cadastro.php e salvá-lo dentro da pasta view.

Este também é um arquivo contendo somente HTML então não darei explicações do mesmo, segue o código:

<html>
<title>CRUD PHP OO Modelo MVC</title>
</head>

<body>
<form action="../controller/CadastroController.php" method="post">
<input type="hidden" name="acao" value="incluir">
Nome: <br /><input type="text" size="30" name="nome"><br />
Idade: <br /><input type="text" size="5" name="idade"><br />
Telefone: <br /><input type="text" size="15" name="telefone">
<p><input type="submit" value="Gravar"> <input type="button" value="Voltar" onClick="document.location='../menu.php'"></p>
</form>

</body>
</html>

No código apresentado, na tag form colocamos no action o caminho do arquivo que será enviado os dados preenchidos pelo usuário, no nosso caso teremos que sair do diretório view e entrar no diretório controller: ../controller/CadastroController.php este caminho será o controle da aplicação.

Agora vamos quebrar um pouco a ordem dos arquivos, pois teremos que criar a classe que fará todas as transações com o banco de dados, a nossa "DAO".

Vou mostrar o código pronto e depois explicar como tudo funciona, salve-o como Banco.php dentro da pasta model:

<?php
class Banco {
	private $sql;
	private $query;
	private $result;
	private $host;
	private $usuario;
	private $senha;
	private $banco;
	public $tabela;
	public $campos; // array
	public $valores; // array
	private $linhas;
	private $camposQuery = null;
	private $valoresQuery = null;

	public function __construct() {
		$this->conexao();
	}

	private function conexao() {
		$this->host    = "localhost";
		$this->usuario = "root";
		$this->senha   = "";
		$this->banco   = "crud";

		mysql_connect($this->host, $this->usuario, $this->senha);
		mysql_select_db($this->banco);
	}

	private function montaQuery($tipo) {
		$cont  = count($this->campos);
		for($i = 0; $i < $cont; $i++) {
			if($i < $cont - 1) {
				if($tipo == 1) {
					$this->camposQuery  .= $this->campos[$i] .", ";
					$this->valoresQuery .= "'" .$this->valores[$i] ."', ";
				} 
			} else {
				if($tipo == 1) {
					$this->camposQuery  .= $this->campos[$i];
					$this->valoresQuery .= "'" . $this->valores[$i] ."'";
				}
			}
		}
	}

	public function inserirRegistro() {
		$this->montaQuery(1);
		$this->sql    = "INSERT INTO ".$this->tabela." (".$this->camposQuery.") VALUES (".$this->valoresQuery.")";
		$this->query  = mysql_query($this->sql);
		$this->result = mysql_affected_rows();

		return $this->result;
	}
}
?>

Dada a classe acima, vemos que é uma classe comum em php, vamos para a explicação:

Declaramos alguns dos seus atributos como "private" e outros como "public", o detalhe é que os públicos serão acessados de fora da classe (em uma classe que herdará suas propriedades e métodos). Os atributos são:

public $tabela - irá receber o nome da tabela que será feita a inclusão no banco de dados, no nosso caso "cadastro".

public $campos - irá receber um array de valores com os nomes dos campos existentes na tabela.

public $valores - irá receber um array de valores com os valores reais que serão inseridos no banco de dados.

Os outros atributos são de uso comum dentro da classe.

public function __construct() {
$this->conexao();
}

Método construtor que irá realizar a conexão com o banco de dados sempre que a classe for instanciada.

private function conexao() {
...
}

Método responsável pela conexão com o banco de dados, configure as propriedades: $this->host, $this->usuario, $this->senha e $this->banco de acordo com suas necessidades.

private function montaQuery($tipo) {
...
}

Método responsável em montar a estrutura do sql, de acordo com o tipo de ação que será passada a ele, nesse caso a ação será 1, que é uma inclusão.

Na sequência do método, ele faz uma contagem de quantos elementos contém o array que foi passado na propriedade $this->campos, monta um laço de índice igual a quantidade de campos, em seguida faz um teste para saber o último campo do array, para não jogar uma vírgula no final da string. Emfim faz a montagem da strings e atribui às suas devidas propriedades: $this->camposQuery e $this->valoresQuery, o resultado ficará, respectivamente, da seguinte forma: $this->camposQuery = nome, idade, telefone; e $this->valoresQuery = 'fulano','34','(61)3333-3333'.

public function inserirRegistro() {
....
}

Método responsável em incluir um registro no banco de dados.

Primeiro ele executa o método montaQuery(), passando como parâmetro o valor 1 que se trata de uma inclusão;

Monta uma string que será o sql para execução (observe que nesse momento passamos as propriedades) : $this->camposQuery e $this->valoresQuery, para a criação da string;

Após a geração da string, a mesma é executada pela função mysql_query();

Fazemos uma contagem das linhas afetadas na transação, com a função mysql_affected_rows(), para sabermos se a query foi executada com sucesso;

E por fim retornamos as linhas afetadas na execução do método, retorno o qual será usado na classe de controle.

Assim finalizamos nossa classe Banco.php a nossa "DAO", que deverá ser salva na pasta (model).

Agora vamos partir para a nossa classe de modelo

Da mesma forma mostrarei o código e darei a explicação:

<?php
require_once("Banco.php");

class Cadastro extends Banco {
	private $nome;
	private $idade;
	private $telefone;

	public function setNome($string) {
		$this->nome = $string;
	}

	public function setIdade($int) {
		$this->idade = $int;
	}

	public function setTelefone($string) {
		$this->telefone = $string;
	}

	public function getNome() {
		return $this->nome;
	}

	public function getIdade() {
		return $this->idade;
	}

	public function getTelefone() {
		return $this->telefone;
	}

	public function incluir() {
		$this->tabela  = "cadastro";
		$this->campos  = array("nome", "idade", "telefone");
		$this->valores = array($this->getNome(),$this->getIdade(),$this->getTelefone());
		$result = $this->inserirRegistro();

		return $result;
	}
}
?>

Primeiro incluímos a classe Banco.php em nossa classe que se chamará Cadastro.php;

A nossa classe Cadastro irá herdar os atributos e métodos da classe Banco;

Criamos os atributos privados da classe $nome, $idade e $telefone e os encapsulamos através dos "set e get" conforme a sequência dos métodos.

public function incluir() {
....
}

Este método é encarregado de passar os valores "setados" pelo controle, para a "DAO" onde será efetuada a transação no banco de dados;

Como nossa classe "class Cadastro extends Banco" herda os atributos de Banco, então podemos acessar diretamente os mesmos:

$this->tabela = "cadastro"; - Informa a tabela que serão gravadas as informações;

$this->campos = array("nome", "idade", "telefone"); - Informa um array com os campos da tabela que serão gravadas as informações;

$this->valores = array($this->getNome(),$this->getIdade(),$this->getTelefone()); - Passa um array com os valores recebidos através dos métodos "get";

$result = $this->inserirRegistro(); - Executa o método inserirRegistro(), que está na classe Banco, armazenando o resultado das linhas afetadas na variável $result;

E por fim dá um retorno no método, este armazenará a quantidade de linhas afetadas na consulta e será avaliado no controle.

Partiremos agora para a classe de controle do nosso sistema.

Da mesma forma mostrarei o código e após as explicações:

<?php
require_once("../model/Cadastro.php");
class CadastroController {

	private $cadastro;

	public function __construct() {
		$this->cadastro = new Cadastro();

		$acao = $_POST['acao'];
		if($acao == "incluir") {
			$this->incluir();
		}
	}

	private function incluir() {
		$this->cadastro->setNome($_POST['nome']);
		$this->cadastro->setIdade($_POST['idade']);
		$this->cadastro->setTelefone($_POST['telefone']);
		$result = $this->cadastro->incluir();
		if($result >=1) {
			echo "<script>alert('Registro incluído com sucesso!');document.location='../view/cad_cadastro.php'</script>";
		} else {
			echo "<script>alert('Erro ao gravar registro!');history.back()</script>";
		}
	}
}
new CadastroController();
?>

Primeiro incluímos o arquivo Cadastro.php que é nossa classe de modelo;

Declaramos um atributo privado: private $cadastro, que será um objeto de Cadastro;

public function __construct() {
....
}

Nosso método construtor instancia o objeto $this->cadastro da classe Cadastro;

Verifica a ação passada no formulário de cadastro através do campo hidden, se a ação for incluir, executa o método incluir que nesta primeira parte será o único apresentado.

private function incluir() {
....
}

Método responsável em "setar" os valores passados pelo formulário para a camada de modelo, através do métodos: setNome(), setIdade() e setTelefone(), sendo referenciado pelo objeto $this->cadastro criado anteriormente;

Na sequência, o método incluir() da classe Cadastro é executado através do objeto $this->cadastro, e o retorno dado na classe Cadastro será armazenado na variável $result;

Então é feita a verificação se o resultado é 1 ou maior que 1, se sim, a query foi executada com sucesso, será apresentada uma mensagem de sucesso para o usuário e em seguida será redirecionado. Em caso de negação será apresentada a mensagem de falha;

E por fim, temos uma instância da própria classe "new CadastroController()", pois precisamos "startar" a classe no momento que ela é invocada pelo action do formulário.

Resumindo tudo isso, temos um menu que chama um form que está na camada de visão (view), quando submetemos o form invocamos uma classe chamada CadastroController.php que pertence à camada de controle, que por sua vez "envia" os dados para a classe Cadastro.php que pertence à camada de controle, esta por sua vez executa o método da classe Banco.php nossa "DAO" que faz a inserção no banco de dados, devolvendo uma resposta às camadas anteriores.

Os arquivos foram todos testados em plataforma Windows e utilizando o pacote EasyPHP-5.3.0

Bom, então é isso, espero que gostem do tutorial e que seja útil para o aprendizado de alguém, qualquer coisa estarei à disposição.

Os arquivos poderão ser baixados no endereço: Clique aqui

Leozitho · Março 28, 2011

Amigo, no título do seu tutorial você colocou "PHP OO" (orientado a objetos), porém eu não consegui encontrar onde está a orientação a objetos aí.

Você está extendendo uma tabela chamada "Cadastro" de outra chamada "Banco", o que cadastro tem a ver com banco de dados pra ser extendida?

E é cadastro do que? Ao meu ver a classe deveria ter o nome do que está sendo cadastrado, por exemplo Cliente, Usuario, Produto, etc. Afinal, "cadastro" não é nome de um objeto.

E já que você está trabalhando supostamente com orientação a objetos, por que está utilizando funções mysql_* que são procedurais? Ficaria muito melhor utilizar PDO ou mysqli neste caso.

Minha intenção não é desmerecer o seu artigo, pelo contrário, acho muito bacana quem compartilha conhecimento. Só fiz essas pequenas críticas (ao meu ver construtivas) porque quem tá começando com orientação a objetos agora pode ter uma idéia errada lendo seu artigo.

Um abraço!

João Batista Neto · Março 28, 2011

Você está extendendo uma tabela chamada "Cadastro" de outra chamada "Banco", o que cadastro tem a ver com banco de dados pra ser extendida?

Perfeito Leozitho :joia:

Leozitho · Março 28, 2011

Valeu João! Muitos conceitos sobre orientação a objetos eu tenho aprendido através das suas verdadeiras aulas aqui no fórum. ^_^

Só acabei trocando o nome classe por tabela. rs

Daniel Ribeiro · Março 28, 2011

Além do que foi mencionado pelo Leozitho, pode-se encontrar alguns OUTROS pontos sem sentido nesta implementação.

A ideia era trabalhar com MVC, correto? Então porque um controllador tem um atributo chamado $cadastro?

Outro detalhe é a implementação de um método responsável por montar uma query. Com a implementação que você fez, é bem difícil (pra não dizer impossível) de se criar consultas complexas.

Minha sugestão é estudar bastante os conceitos de orientação a objetos, de preferência afastados da implementação.

Não tente entender um padrão de arquitetura de software, como o MVC, se não sabe, ainda, como deve, basicamente, funcionar um software.

William Bruno · Março 29, 2011

minha opinião a respeito dos comentários, é:

É simples vir aqui e criticar, quero é ver um de vocês terem a coragem de desenvolver o que foi proposto da forma 'mais correta' como vcs pregam. Bacana.. tá 'errado', 'precisa melhorar'.

Então postem ai. Dêem as caras de vcs a tapa, como o Quelipe foi corajoso para fazer.

Aguardo para ver as implementações de vcs.

Leozitho · Março 29, 2011

William,

Acredito que a questão aqui não é ser corajoso ou dar a cara pra bater, o problema é que ao escrever um artigo com conceitos errados sobre orientação a objetos pode prejudicar e muito o aprendizado de muitos que estão tentando aprender orientação a objetos e que venham a ler este artigo. Isso se chama desinformação, tentar ensinar algo errado para outras pessoas.

Eu sou humilde o suficiente pra admitir que ainda estou estudando orientação a objetos, já comprei alguns livros sobre PHP orientado a objetos e sobre design patterns, portanto, como ainda não domino completamente o assunto não vou me arriscar querendo "ensinar" os outros. Ao meu ver isso não é questão de não ter coragem de dar a cara pra bater como você disse, e sim ter responsabilidade de não sair ensinando coisas erradas para os outros.

Também não é porque não domino completamente o assunto que devo me calar ao ver que alguém está ensinando algo errado.

William Bruno · Março 29, 2011

Oi @Leozitho,

Okay, agora sim estamos fazendo disso aqui um fórum!

Concordo com o que você disse, e realmente os pontos que você levantou na sua análise do sistema são importantes.

Desinformação certamente é um problema. Louvável sua atitude e compreensão da extensão dos teus conhecimentos. O caminho é esse. Vamos todos estudar para melhorarmos e entendermos direito o que é cada coisa.

Só não podemos esquecer que da mesma forma que está incorreto o que foi proposto, o próprio autor, não o fez 'por maldade', ele apenas também não sabe como deveria ser. Ao menos tentou. Os erros foram apontados, eu quero os instigar a não pararmos por aqui, ou então não esperarmos que a correção venha do próprio.

Por exemplo:

Então porque um controllador tem um atributo chamado $cadastro?

e daí ?

O problema não é esse atributo, e ele pode existir nesse contexto.

Outro detalhe é a implementação de um método responsável por montar uma query. Com a implementação que você fez, é bem difícil (pra não dizer impossível) de se criar consultas complexas.

E daí ?

scripts são escritos para resolver problemas especificos e bem definidos. Se o método dele, teve como intenção resolver a questão de montar queries simples, então serviu ao propósito ao qual foi desenhado, e está muito bem assim.

Se precisar de queries mais complexas, não será 'complicando' este método em específico a melhor solução para tal.

Que tal então, definirmos bem o que precisamos, detalharmos o que vamos fazer, e programarmos pareando o código?

Assim, com base no problema proposto, vamos em comunidade levantar uma solução para tal.

João Batista Neto · Março 29, 2011

Que tal então, definirmos bem o que precisamos, detalharmos o que vamos fazer, e programarmos pareando o código?

Assim, com base no problema proposto, vamos em comunidade levantar uma solução para tal.

Fantástico William :clap:

Não sei se todos já sabem, mas o iMasters possui um perfil no Github :seta: iMastersDev

O iMasters Developer tem como objetivo reunir códigos úteis para toda a comunidade de desenvolvedores e essa sua ideia vai exatamente de encontro com a proposta.

Minha sugestão é uma aplicação que resolve um problema do dia a dia de muitos desenvolvedores:

Sistema Gerenciador de Projetos.

1. Cadastro e manipulação de clientes.

2. Cadastro e manipulação de projetos.

3. Cadastro e manipulação de desenvolvedores.

4. Atribuição de projetos para clientes.

5. Atribuição de tarefas para projetos.

6. Atribuição de tarefas para desenvolvedores.

Se estiverem mesmo dispostos a desenvolver uma aplicação colaborativa, criamos o repositório no iMastersDev, definimos um time para desenvolvê-la, especificamos, modelamos e começamos a implementar a aplicação.

O que acham ?

Daniel Ribeiro · Março 29, 2011

@William Bruno

Sinto que as suas respostas são um tanto hostis, William. Estou enganado?

Quando comentei sobre as questões técnicas, falei do ponto de vista da análise e projeto orientado a objetos.

Em nenhum momento disse que o autor do tópico o criou com maldade.

A questão aqui, como bem comentou o Leozitho, não é maldade ou coragem, e sim responsabilidade.

O ensino é uma grande responsabilidade.

Mais uma vez, não tive a intenção de ser agressivo com minha resposta, se entendeste assim.

Estava apenas lançando críticas para que todos evoluamos juntos.

Compreende? ^_^

@João

Estamos falando de desenvolvimento ágil? Não entendi perfeitamente a proposta.

João Batista Neto · Março 29, 2011

Estamos falando de desenvolvimento ágil? Não entendi perfeitamente a proposta.

Não, estamos falando de desenvolvimento colaborativo:

1. Criamos um repositório.

2. Criamos um time.

3. Desenvolvemos uma aplicação.

just simple.

Daniel Ribeiro · Março 29, 2011

Legal, a ideia é muito boa.

Talvez não consiga participar efetivamente do desenvolvimento, por falta de tempo, mas posso ajudar com a análise ou o levantamento de requisitos.

E com certeza vou usar a aplicação.

:clap:

Quelipe · Março 29, 2011

Leozitho

Amigo, no título do seu tutorial você colocou "PHP OO" (orientado a objetos), porém eu não consegui encontrar onde está a orientação a objetos aí.

Cara com suas palavras, sem ctrl+c ctrl+v, o que é orientação a objetos para você?

Você está extendendo uma tabela chamada "Cadastro" de outra chamada "Banco", o que cadastro tem a ver com banco de dados pra ser extendida?

Certo, concordo com você que está errado da maneira que fiz, mas explique para todos o porque não pode fazer dessa forma.

E é cadastro do que?

Essa é simples, é um cadastro de exemplo, você não percebeu?

Valeu João! Muitos conceitos sobre orientação a objetos eu tenho aprendido através das suas verdadeiras aulas aqui no fórum

Vejo que se não tiver alguém para se escorar, ou se inspirar não tem respostas cabíveis.

Daniel R. Gomes

A ideia era trabalhar com MVC, correto? Então porque um controllador tem um atributo chamado $cadastro?

Não pode? Explique para todos "com suas palavras" o porque.

Outro detalhe é a implementação de um método responsável por montar uma query. Com a implementação que você fez, é bem difícil (pra não dizer impossível) de se criar consultas complexas.

Dê um exemplo de "query" complexa, lembrado, o que está implementado aí é apenas um INSERT.

Apesar de tudo, até mesmo de vocês não terem nem um perfil cadastrado no fórum, para mostrar o que fazem, onde trabalha se ganham dinheiro com php, gostei das críticas vai ser bom para mim, melhor ainda depois que responderem as questões que levantei.

Um conselho mostre sua cara, edite um perfil, mostre o que vocês fazem, pois, assim ficarei feliz por receber críticas de gente que trabalha realmente na área, de gente que realmente entende do assunto.

At+

Daniel Ribeiro · Março 29, 2011

@Quelipe

Amigo, mais uma vez vou repetir: não se sinta ofendido pelas críticas feitas à sua pessoa. Tudo o que eu falei foi no intuito de ajudar as pessoas (inclusive você), visto que alguns conceitos estão mal interpretados.

Veja bem, mal interpretados, e não completamente errados.

No padrão de arquitetura MVC, qual a função do controller?

É, basicamente, interpretar as requisições feitas pelo usuário, acionar os recursos disponíveis para responder essa requisição e enviar uma resposta.

Preste bastante atenção à palavra acionar. O controller geralmente aciona um model para responder às requisições do usuário, mas nem sempre isso acontece.

Portanto, um controller não depende de um model para existir.

Se hoje você tem um atributo que armazena um model no controller, amanhã você pode, despretensiosamente, adicionar regras de domínio em uma ação deste controller.

E é aí que mora o perigo.

Percebe?

Leozitho · Março 29, 2011

@Quelipe,

Pelo visto você ficou bastante irritado com as críticas construtivas que foram feitas ao seu artigo. Sim, construtivas, pois se não servir pra você reescrever ou tentar melhorar o seu artigo, pelo menos serve como alerta para quem ler saber que o que você expõe não segue a risca os conceitos de orientação a objetos.

Infelizmente o que poderia ser uma discussão saudável e construtiva sobre o assunto está se transformando em ataques pessoais, então acho melhor parar por aqui. Você está tentando nos intimidar e nos desqualificar, alegando que porque não expomos completamente nossas vidas pessoais e profissionais em nossos perfis aqui no fórum, não somos profissionais da área.

Eu não tenho que explicar o que é orientação a objetos, pois se você quiser mesmo saber o que é existem livros e artigos com essa finalidade. Minha intenção não é ensinar ninguém, apenas expus problemas que notei no seu artigo.

E com relação a um dos ataques pessoais que você fez a mim, não, eu não fico me escorando em ninguém. Eu apenas agradeci o comentário do nosso colega João e fui humilde o suficiente pra dizer que tenho aprendido sobre o assunto também com os excelentes artigos escritos por ele aqui no fórum. ;)

Daniel Ribeiro · Março 29, 2011

@Quelipe,

Pelo visto você ficou bastante irritado com as críticas construtivas que foram feitas ao seu artigo. Sim, construtivas, pois se não servir pra você reescrever ou tentar melhorar o seu artigo, pelo menos serve como alerta para quem ler saber que o que você expõe não segue a risca os conceitos de orientação a objetos.

Infelizmente o que poderia ser uma discussão saudável e construtiva sobre o assunto está se transformando em ataques pessoais, então acho melhor para por aqui. Você está tentando nos intimidar e nos desqualificar alegando que porque não expomos nossas vidas pessoais e profissionais em nossos perfis aqui no fórum não somos profissionais da área.

Eu não tenho que explicar o que é orientação a objetos, pois se você quiser mesmo saber o que é existem livros e artigos com essa finalidade. Minha intenção não é ensinar ninguém, apenas expus problemas que notei no seu artigo.

E com relação a um dos ataques pessoais que você fez a mim, não, eu não fico me escorando em ninguém. Eu apenas agradeci o comentário do nosso colega João e fui humilde o suficiente pra dizer que tenho aprendido sobre assunto também com os excelentes artigos escritos por ele aqui no fórum. ;)

Tive, exatamente, a mesma sensação.

Acho melhor parar por aqui, mesmo.

André Severino · Março 30, 2011

Boa noite pessoal, desde o dia que o nosso amigo Quelipe postou este tutorial, estou acompanhando o desenrolar dessa situação pois fiquei muito interessado em saber onde ele 'errou' e gostaria muito de descobrir isso para me precaver em meus projetos futuros e tenho quase toda certeza que se outro usuário ver isso ele vai ficar intrigado da mesma forma e até agora não opniei pois ainda estou aprendendo o paradigma de OO/gof/mvc/design patterns e outros detalhes.

Pelo fato de estar aprendendo não tenho como criticar ou até mesmo 'melhorar' algo, mas por favor como consta no titulo do post essa é a primeira parte do tutorial, 'CRUD com PHP OO e MVC Parte 1', e não vamos parar por aqui. Vamos dar continuidade nisso juntos!!. (Espero que daqui há algum tempo eu possua conhecimento suficiente para criar tutoriais e ajudar usuarios futuros) :thumbsup:

Se os nossos amigos Leo e Daniel tiver algum tempo disponivel e colaborar com esse artigo poderemos sanar varias duvidas futuras de usuarios que irá ler esse material. A questão é que devemos melhorar isso ao ponto de que conforme o usuario for lendo ele perceba onde estão as falhas e procurar não fazer isso em seus projetos.

Com relação ao tópico, vou deixar algumas sugestões(duvidas também) com relação ao código.

Na página Banco.php, alterei o metodo montaQuery()

private function montaQuery($tipo) {
 if($tipo == 1) {
    $this->camposQuery = '`'.implode('`, `', array_values($this->campos)).'`';
    $this->valoresQuery= "'".implode("', '", array_values($this->valores))."'";
 }
}
// Saida:
# string(27) "`nome`, `idade`, `telefone`"
# string(31) "'Marcelo ', '22', '19 58785632'"

Removi os for's,if's, e utilize o array_values com o implode para montar a string. Outro detalhe importante é que poderiamos retornar a query inteira nesse metodo e também os valores do campos poderiamos passar nas chaves do array, desta forma abstraimos as keys/values sendo campos/valores. Fica a dica.

- Aqui não deveriamos utilizar um self::metodo(), tendo em vista que o metodo conexao é privado e está dentro da mesma classe? Pois o $this->conexao() da impressao que ele esta se referindo ha alguma atributo(variavel) da classe. É claro que tem a questão dos 2 parenteses no final () que significa um método... Mas o certo seria $this, self ou nenhum dos 2 ?

public function __construct() {
  $this->conexao();
  //self::conexao();
}

Ainda na questão do método conexao(), note-se que foi aberta uma conexão com banco de dados. Não deveriamos adicionar a conexão em uma variavel e depois criar uma método para fechar essa conexão?

private function conexao() {
// atributos

$con = mysql_connect($this->host, $this->usuario, $this->senha);
$db  = mysql_select_db($this->banco);
}
public function finalizarConexao() {
 mysql_close($con);
}

Na página Cadastro.php

class Cadastro extends Banco {
private $nome;
private $idade;
private $telefone;

// Metodos setNome, setIdade, setTelefone
// Metodos getNome, getIdade, getTelefone

public function incluir() {
  $this->valores = array($this->getNome(),$this->getIdade(),$this->getTelefone());
}
}

O método incluir utiliza $this->getNome(),etc. Sabendo-se que no começo ele declara valores aos atributos da classe $nome, $idade, $telefone através dos metodos set. Eu não deveria usar algo como $this->nome/self::nome ? Pois como metodo está dentro da classe e os atributos também eu não preciso retornar o valor através de 3 métodos. Isto está certo ?

Outra coisa é o fato de herdar propriedades da clase Banco (Cadastro extends Banco)

Exemplos seguindo essa linha de pensamento:

- Para visualizar um cadastro ele teria que criar uma classe ViewCadastro extends Banco, fazer a conexão e depois criar uma método para fazer o select?

- Para atualizar ele teria que criar uma outra classe UpdateCadastro extends Banco, fazer uma nova conexão com o banco de dados e criar um novo método para fazer o update ?

Não poderia criar os 4 metodos (select, insert, update, delete) em uma unica classe e depois extender esses metodos ?

Obrigado a atenção de todos e desculpe o post grande. Caso tenha a paciencia de ler e se puder esclarecer algumas dúvidas ficarei muito grato e até mais :thumbsup:

djeico · Março 9, 2016

Uma pena que o post tenha parado.

Se pelo menos tivessem informado como implementar corretamente o que ~~supostamente~~ está errado...

MAARCOSOO · Abril 4, 2016

Meus amigos, acho uma grande pena que os posts tenham se encerrado. Fiz exatamente como o @Quelipe indicou, adaptei para o meu formulário e deu super certo o a inclusão de dados no banco. Gostaria mt de ter um resultado final deste post, e todos se ajudando para deixar o artigo 100% correto...

Gabriel Heming · Abril 4, 2016

O fato é que não existe 100% correto, ou verdade absoluta. Existe o correto dentro de uma abordagem .

Visto que, a ideia aqui presente, é criar CRUD PHP OO, não há nenhuma informação a mais disso. É importante definir os limites antes de iniciar o desenvolvimento, como por exemplo:

- Tipos de storage: existem inúmeros, desde SQL, NoSQL, file system, etc..;

- Flexibilidade: qual o nível de flexibilidade a abstração é o desejado.

Digamos que, nós queremos deixar flexível para os principais SGBDs SQL (MySQL, PostgreSQL, Oracle e SQL Server). Um tipo de flexibilidade, foi definido, mas uma leva a outra. O quão flexível?

Todos os SGBDs citados, possuem peculiaridades em SQL. A escrita correta deve ser realiza pelo desenvolvedor ou deve-se criar uma camada para abstrair a escrita do SQL?

E isso é apenas a questão de análise e levantamento de requisitos, o que existe de análise no tópico, é apresentado no decorrer do texto (o que é bom) ou dos códigos (o que é ruim).

Quanto aos problemas de design apresentados.

- Um cadastro não é um banco. Um cadastro utiliza a conexão com banco (apesar do nome, vamos usar o termo storage);

- A classe cadastro (não consigo entender a motivação do seu nome), é uma entity;

- Uma entity não "se salva/inclui";

- Um storage, do ponto de vista da programação, não cria queries e/ou registros. Um storage recebe e executa instruções. Essas instruções podem ou não gerar um registro;

- Os parâmetros de conexão estão fixos dentro do Storage. Devem ser uma dependência.

Conforme fosse corrigindo os problemas acima listados, mais iriam surgir. Mas não devido ao código já escrito e sim ao escopo e sua necessidade.

Entretanto, assim como o Active Record, que é um padrão documentado, não é recomendado por causa de sua quebra de responsabilidade única, quem garante que, tudo que o autor do tópico representou não esteja documentado em algum lugar? Apesar dos problemas já apresentados.

Além do mais, o exemplo de CRUD é o pior possível para se apresentar uma solução definitiva. Ele é excelente como estudo de caso entre custo x benefício. Mas, para apresentar uma solução definitiva, o custo seria tão alto, que os benefícios não valeriam o esforço.

Arquivado

CRUD com PHP OO e MVC Parte 1

Recommended Posts

Quelipe 15

Compartilhar este post

Link para o post

Compartilhar em outros sites

Leozitho 81

Compartilhar este post

Link para o post

Compartilhar em outros sites

João Batista Neto 448

Compartilhar este post

Link para o post

Compartilhar em outros sites

Leozitho 81

Compartilhar este post

Link para o post

Compartilhar em outros sites

Daniel Ribeiro 4

Compartilhar este post

Link para o post

Compartilhar em outros sites

William Bruno 1501

Compartilhar este post

Link para o post

Compartilhar em outros sites

Leozitho 81

Compartilhar este post

Link para o post

Compartilhar em outros sites

William Bruno 1501

Compartilhar este post

Link para o post

Compartilhar em outros sites

João Batista Neto 448

Compartilhar este post

Link para o post

Compartilhar em outros sites

Daniel Ribeiro 4

Compartilhar este post

Link para o post

Compartilhar em outros sites

João Batista Neto 448

Compartilhar este post

Link para o post

Compartilhar em outros sites

Daniel Ribeiro 4

Compartilhar este post

Link para o post

Compartilhar em outros sites

Quelipe 15

Compartilhar este post

Link para o post

Compartilhar em outros sites

Daniel Ribeiro 4

Compartilhar este post

Link para o post

Compartilhar em outros sites

Leozitho 81

Compartilhar este post

Link para o post

Compartilhar em outros sites

Daniel Ribeiro 4

Compartilhar este post

Link para o post

Compartilhar em outros sites

André Severino 3

Compartilhar este post

Link para o post

Compartilhar em outros sites

djeico 0

Compartilhar este post

Link para o post

Compartilhar em outros sites

MAARCOSOO 0

Compartilhar este post

Link para o post

Compartilhar em outros sites

Gabriel Heming 766