Classe CRUD com PDO

Thadeu Esteves · Outubro 11, 2013

@Thadeu, globais cara, não use...

Model singleton??? Hmmm, não é uma boa ideia. Aliás, o que você chama de model não é exatamente um Model, é apenas uma camada de acesso a banco de dados, que está contida no Model.

Aqui vai mais um exemplo, utilizando MySQLi invés de PDO:

http://henriquebarcelos.in/blog/2012/08/20/php-oo-classe-simples-para-acesso-a-banco-de-dados/

@Henrique, Qual o motivo de não se utilizar globais? Tire como exemplo o framework CodeIgniter que segundo pesquisas indicam que esteja entre os 3 melhores frameworks de PHP da atualidade, e que UTILIZA GLOBAIS.

No meu caso eu utilizo uma global para verificar qual o tipo de ambiente que estou desenvolvendo(se não percebeu), que por sinal é muito parecido com o CodeIgniter(CI). Isso possibilita que eu possa trabalhar com até 3 bancos de dados diferentes,so modificando um array.

Verifiquei sua classe http://henriquebarce...banco-de-dados/ e encontrei muitos erros e muitos detalhes que estão ultrapassados para desenvolvedores atualizados, não preciso entrar em detalhes porque seria anti-ético.

@Henrique Devemos evitar o máximo possível escrever códigos SQL, por isso devemos utilizar ActiveRecord, MVC,TableDataGateway e outros padrões que muitas pessoas acham que não são importantes, mas que fazem grande diferença no runtime de uma aplicação.

Conheço seu blog e sei que você é um ótimo desenvolvedor :D por isso, todo conselho é bem-vindo e anotei sua sugestão e vou estudar e trabalhar para melhorar ainda mais meu codigo.

Obrigado mesmo cara de coração.

Abraços!!!!

Evandro Oliveira · Outubro 11, 2013

@Henrique, Qual o motivo de não se utilizar globais? Tire como exemplo o framework CodeIgniter que segundo pesquisas indicam que esteja entre os 3 melhores frameworks de PHP da atualidade, e que UTILIZA GLOBAIS.

Mais utilizado não significa, necessariamente, melhor.

Segundo pesquisas encomendadas por quem? Pela EllisLab?

No meu caso eu utilizo uma global para verificar qual o tipo de ambiente que estou desenvolvendo(se não percebeu), que por sinal é muito parecido com o CodeIgniter(CI). Isso possibilita que eu possa trabalhar com até 3 bancos de dados diferentes,so modificando um array.

Para isso, você pode utilizar constantes ou até mesmo um arquivo de configurações externo.

Verifiquei sua classe http://henriquebarce...banco-de-dados/ e encontrei muitos erros e muitos detalhes que estão ultrapassados para desenvolvedores atualizados, não preciso entrar em detalhes porque seria anti-ético.

O fórum existe exatamente para debater e crescermos juntos. Não há anti ética em questionar os motivos de qualquer abordagem que seja. Ajuda a entender quando podemos quebrar as regras ;)

Ou foi anti ético ele questionar sua decisão sobre globais?

Edit: quanto às técnicas ultrapassadas, acho que você verificou a data de postagem do artigo?

Marcelo Garbin · Outubro 11, 2013

Gurizada medonha!

Eu to começando.. relaxam aí! rsrsrsrs.....

To me "matando" pra sair da casinha do tal procedural e partir pro POO...

Minhas dificuldade inicial, com a classe que postei no primeiro post deste tópico, esta fazendo esse serviço aqui => CRUD

Porém entre as ajudais ai preciso mudar muita coisa nela, uma coisa que gostaria de mudar é a conexão, gostaria de fazer algo parecido com a que você fez @Henrique, utilizando PDO.

Como posso fazer?

Exemplo: Tenho 2 Classes, 1 onde tem o CRUD e outra onde tem a conexão com o PDO.

Como faço para passar os parametros e criar o objeto do PDO no construct do CRUD? Isso que não consegui ainda...

Estou tentando, daqui a pouco tenho aula, mas vou continuar vendo isso até conseguir rsrsrs...

Enrico Pereira · Outubro 12, 2013

Qual o motivo de não se utilizar globais? Tire como exemplo o framework CodeIgniter que segundo pesquisas indicam que esteja entre os 3 melhores frameworks de PHP da atualidade, e que UTILIZA GLOBAIS.

O motivo é óbvio: comportamento inesperado, dificuldade para testar, acoplamento. Uma simples pesquisa no Google poderia abrir os horizontes.

Eu não quero entrar em motivo de framework x ou y, mas o CodeIgniter é um dos frameworks mais mal feitos. Ele é popular porque é fácil de um iniciante qualquer usar, não porque ele é bom. Hoje em dia, Symfony2 e ZF2 são os frameworks mais modernos/usados e eles evitam estado global.

No meu caso eu utilizo uma global para verificar qual o tipo de ambiente que estou desenvolvendo(se não percebeu), que por sinal é muito parecido com o CodeIgniter(CI). Isso possibilita que eu possa trabalhar com até 3 bancos de dados diferentes,so modificando um array.

Dê uma olhada no Dependency Injection Container do Symfony2. Ele te fornece um mecanismo bem completo de configuração, muito superior do que colocar arrays globais :sick:.

Verifiquei sua classe http://henriquebarce...banco-de-dados/ e encontrei muitos erros e muitos detalhes que estão ultrapassados para desenvolvedores atualizados, não preciso entrar em detalhes porque seria anti-ético.

Anti-ético é falar mal duma pessoa, não dum código. O código não representa a pessoa.

Devemos evitar o máximo possível escrever códigos SQL, por isso devemos utilizar ActiveRecord, MVC,TableDataGateway e outros padrões que muitas pessoas acham que não são importantes, mas que fazem grande diferença no runtime de uma aplicação.

Em sistemas muito complexos, ORMs podem não escalar. Em projetos pequenos, podem ser muito complexos e pesados para resolver um simples problema. Há uma discussão eterna nisso, não é uma regra.

Como faço para passar os parametros e criar o objeto do PDO no construct do CRUD? Isso que não consegui ainda...

Qual a dificuldade? o PDO deveria ser passado para o construct, a classe CRUD não deveria criar o PDO. Poste o código que você está tentando fazer ;).

Marcelo Garbin · Outubro 12, 2013

Qual a dificuldade? o PDO deveria ser passado para o construct, a classe CRUD não deveria criar o PDO. Poste o código que você está tentando fazer ;).

É que eu nunca usei classes, e o material que estou usando de estudo pego da internet.. então tem muita coisa que é antiga ou não é a melhor forma de fazer, quero aprender desde o começo o que é certo...

To fazendo uns testes aqui, teria como ver se isso esta certo?

Ou não é assim?

Connect.inc.php

<?php

class BD extends PDO{
	private $conn;

	function __construct($conn = null){
		$this->conn = $conn;
		$this->Connect($this->conn);
	}	

	function Connect($conn = null){
		try{
		    $this->conn = parent::__construct($this->conn['driver'].':host='.$this->conn['host'].';dbname='.$this->conn['dbname'], $this->conn['user'], $this->conn['pass']);
		    $this->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
		    return $this->conn;
		}catch(PDOException $e){
		    echo '<br /><strong>Erro ao se conectar no servidor!</strong><br /><strong>Linha:</strong> '.$e->getLine().' / <strong>Código:</strong> '.$e->getCode().'<br />';
		}
	}

	function __destruct(){
		$this->conn = null;
	}
}

crud.class.php

<?php 

require_once("Connect.inc.php");

class CRUD extends BD{

	private $sql;
	private $pdo;

	function __construct($pdo = null){
		$this->pdo = $pdo;
		$this->pdo = new BD($this->pdo);
	}

	function select(){
		foreach ($this->pdo->query("SELECT * FROM tb_names") as $row) {
			print $row['name'] . $row['surname'] . "<br>";
		}
	}

}

index.php

<!doctype html>
<html lang="en">
<head>
	<meta charset="UTF-8">
	<title>Teste PDO</title>
</head>
<body>
<?php
	require_once("crud.class.php");

	$obj = new CRUD(array("driver"=>"mysql","host"=>"localhost","dbname"=>"testes","user"=>"root","pass"=>""));
	
	$obj->select();
?>
</body>
</html>

Enrico Pereira · Outubro 12, 2013

Vish... vamos lá :lol:.

É que eu nunca usei classes, e o material que estou usando de estudo pego da internet.. então tem muita coisa que é antiga ou não é a melhor forma de fazer, quero aprender desde o começo o que é certo...

De fato, você tem que tomar cuidado. Eu sugiro que você pesquise material sobre OOP em Java, pois o conteúdo é bem mais elaborado geralmente, em PHP há muita "porcaria".

O primeiro passo é pensar em objetos, não em classes.

class BD extends PDO{
	private $conn;

	function __construct($conn = null){
		$this->conn = $conn;
		$this->Connect($this->conn);
	}	

	function Connect($conn = null){
		try{
		    $this->conn = parent::__construct($this->conn['driver'].':host='.$this->conn['host'].';dbname='.$this->conn['dbname'], $this->conn['user'], $this->conn['pass']);
		    $this->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
		    return $this->conn;
		}catch(PDOException $e){
		    echo '<br /><strong>Erro ao se conectar no servidor!</strong><br /><strong>Linha:</strong> '.$e->getLine().' / <strong>Código:</strong> '.$e->getCode().'<br />';
		}
	}

	function __destruct(){
		$this->conn = null;
	}
}

- Qual o propósito de ter NULLs?

- Qual é o propósito de criar uma classe para passar arrays de forma bonitinha?

- Qual é o propósito de ter o método Connect público se o construct já realiza a operação? => There's more than one way to do it.

- Você não precisa de um destruct, o PHP já é inteligente o suficiente e possui Garbage Collector.

class CRUD extends BD{

Um dos erros mais comuns. Herança tem um significado: é um.

Quando nós estendemos uma classe, semanticamente declaramos que a classe é um tipo da que está sendo estendida. Por exemplo: se dizemos que a classe SQLite vai estender Database, eu estou dizendo que SQLite é um Database, que nesse caso faz sentido.

Sempre que for estender, pergunte: essa classe é um tipo da outra? se for, herança pode ser adequada.

CRUD é um BD? Não => não use herança

SQLite é um BD? Sim => pode usar herança

	private $sql;

Por que essa propriedade foi definida?

	function __construct($pdo = null){
		$this->pdo = $pdo;
		$this->pdo = new BD($this->pdo);

Não dá para entender. Por que você permite null, define uma propriedade uma vez e depois a redefine? WTF?

Marcelo Garbin · Outubro 14, 2013

Opa! Bora lá então no meu modo de entender as coisas hehe...

- Qual o propósito de ter NULLs?

O propósito de ter null no parametro seria da validação, exemplo do uso de null que eu faria, não sei se isso estaria certo, mas por fim resolveria o Warning e Notice que daria pelo fato da variável passada pelo parametro não estar definida.

Exemplo do meu código:

function select($sql = null){
		$this->sql = $sql;
		try{
			if($this->sql){
				foreach($this->pdo->query($this->sql) as $row) {
					print $row['name'] . $row['surname'] . "<br>";
				}
			}else{
				echo "Exemplo de msg erro query null!";
			}
		}catch(PDOException $e){
			echo '<br /><strong>Erro ao se conectar no servidor!</strong><br /><strong>Linha:</strong> '.$e->getLine().' / <strong>Código:</strong> '.$e->getCode().'<br />';
		}
	}

- Qual é o propósito de criar uma classe para passar arrays de forma bonitinha?

Por que seria bonitinha? Vejo pelo lado mais pratico, ao invés de eu passar 5 parametros, passo apenas um. Qual motivo de não usar array?

- Qual é o propósito de ter o método Connect público se o construct já realiza a operação? => There's more than one way to do it.

Boa pergunta, talvez pela validação ou por eu não saber que poderia ir direto no construct!? hehehe... Refiz da seguinte forma o Connect.inc.PHP, Seria desse jeito?

<?php

class BD extends PDO{
	private $conn;

	function __construct($conn){
		$this->conn = $conn;
		try{
	        parent::__construct($this->conn['driver'].':host='.$this->conn['host'].';dbname='.$this->conn['dbname'], $this->conn['user'], $this->conn['pass']);
	        $this->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
	    }catch(PDOException $e) {
    		echo '<br /><strong>Erro ao se conectar no servidor!</strong><br /><strong>Linha:</strong> '.$e->getLine().' / <strong>Código:</strong> '.$e->getCode().'<br />';
	    }
	}	
}

- Você não precisa de um destruct, o PHP já é inteligente o suficiente e possui Garbage Collector.

Ok, não sabia dessa parte, achei que poderia ser interessante utilizar o __destruct no quisito uso de recursos do servidor e segurança, acabei lendo uns post e vi que não é necessário o mesmo.

Sempre que for estender, pergunte: essa classe é um tipo da outra? se for, herança pode ser adequada.
CRUD é um BD? Não => não use herança
SQLite é um BD? Sim => pode usar herança

Entendido!

No primeiro momento extendi o BD para o uso dos métodos do PDO, mas não é necessário como você explicou nesse post.

Por que essa propriedade foi definida?

Eu defini o $sql para fazer a validação antes de sua execução e também passar o comando via parametro, para posteriormente utilizar em um log por exemplo.

Não dá para entender. Por que você permite null, define uma propriedade uma vez e depois a redefine? WTF?

Mais uma vez pela validação que poderia fazer posteriormente, mas como é usado o try/catch não sei se seria necessário.

Bom o crud.class.php ficou dessa forma (lembrando que é apenas exemplo):

<?php 

require_once("Connect.inc.php");

class CRUD{
	private $sql;
	private $pdo;

	function __construct($pdo){
		$this->pdo = new BD($pdo);
	}

	function select($sql = null){
		$this->sql = $sql;
		try{
			if($this->sql){
				foreach($this->pdo->query($this->sql) as $row) {
					print $row['name'] . $row['surname'] . "<br>";
				}
			}else{
				echo "Exemplo de msg erro query null!";
			}
		}catch(PDOException $e){
			echo '<br /><strong>Erro ao se conectar no servidor!</strong><br /><strong>Linha:</strong> '.$e->getLine().' / <strong>Código:</strong> '.$e->getCode().'<br />';
		}
	}
}

Diante disso, mais algum erro que estou cometendo? Pergunto isso pois aqui esta funcionando desse jeito... Então logo pra mim estaria tudo ok. Agora não sei no padrão do código/desenvolvimento se estaria tudo certo.

Enrico Pereira · Outubro 14, 2013

O propósito de ter null no parametro seria da validação, exemplo do uso de null que eu faria, não sei se isso estaria certo, mas por fim resolveria o Warning e Notice que daria pelo fato da variável passada pelo parametro não estar definida.

Você não está se ajudando com isso, mas sim se atrapalhando.. você NÃO VAI passar um SQL em branco, logo o parâmetro é obrigatório. Se você não passar, tem mesmo que dar erro, afinal é o correto. Tire esses NULLs daí...

Por que seria bonitinha? Vejo pelo lado mais pratico, ao invés de eu passar 5 parametros, passo apenas um. Qual motivo de não usar array?

Você não tem controle sobre um array. Array é um tipo primitivo e você só está fazendo uma coisa "bonitinha", sem fundamento algum (e está passando 5 parâmetros, só que num array). Esse artigo é bacana: http://blog.augustopascutti.com/php/2010/12/06/arrays-nunca-mais.html

Boa pergunta, talvez pela validação ou por eu não saber que poderia ir direto no construct!? hehehe... Refiz da seguinte forma o Connect.inc.PHP, Seria desse jeito?

Sim, mas veja novamente: você está criando uma classe desnecessária e não dê um echo, deixe a exception rolar e use set_exception_handler ou um try/catch na hora de usar. Colocar um echo na classe é terrível, diminui a facilidade de reutilização e mais cedo ou mais tarde você terá um belo Headers already sent na sua frente. Além disso, não use HTML diretamente: e se eu quiser usar essa classe pela linha de comando e não pela web?

---

Você ainda tem o acoplamento, código desnecessário, pouco reutilizável e falta autoloading. Todas essas classes na verdade são desnecessárias. Tudo o que você precisa é de um objeto PDO, de alguém que vá controlá-lo e de uma view.

Como você está preocupado com os erros (não que esteja errado...), um framework de 300 linhas de código que resolve o problema de erros e view, usando PSR-0:

src/MinimalisticFramework/View.php:

<?php
namespace MinimalisticFramework;

class View {
    private $file;
    private $params;

    /**
     * @param string $file
     * @param array $params
     */
    public function __construct($file, array $params = []) {
        $this->file = $file;
        $this->params = $params;
    }

    /**
     * @return string
     */
    public function render() {
        ob_start();
        extract($this->params);
        require $this->file;
        $content = ob_end_clean();
        return $content;
    }
}

src/MinimalisticFramework/ErrorHandler.php

<?php
namespace MinimalisticFramework;

use Exception;

interface ErrorHandler {
    /**
     * @param \Exception $e
     * @return View
     */
    public function handle(Exception $e);
}

src/MinimalisticFramework/ErrorDispatcher.php

<?php
namespace MinimalisticFramework;

use ErrorException;

class ErrorDispatcher
{
    private $errorHandler;

    /**
     * @param ErrorHandler $errorHandler
     */
    public function __construct(ErrorHandler $errorHandler)
    {
        $this->errorHandler = $errorHandler;
    }

    /**
     * @param callable $app
     */
    public function run(callable $app)
    {
        set_error_handler(function ($errno, $errstr, $errfile, $errline) {
            throw new ErrorException($errstr, $errno, 0, $errfile, $errline);
        });

        register_shutdown_function(function () {
            $error = error_get_last();

            if (null === $error) {
                return;
            }

            throw new ErrorException($error['message'], $error['type'], 0, $error['file'], $error['line']);
        });

        try {
            $app();
        } catch (Exception $e) {
            echo $this->errorHandler->handle($e)->render();
        }
    }
}

src/App/WebErrorHandler.php

<?php
namespace App;

use MinimalisticFramework\ErrorHandler;
use Exception;
use MinimalisticFramework\View;

class WebErrorHandler implements ErrorHandler {
    public function handle(Exception $exception)
    {
        return new View(
            __DIR__ . '/../../views/error.phtml',
            ['exception' => $exception]
        );
    }
}

src/App/UserController.php

<?php
namespace App;

use PDO;
use MinimalisticFramework\View;

class UserController {
    private $pdo;

    public function __construct(PDO $pdo)
    {
        $this->pdo = $pdo;
    }

    public function getAllUsers()
    {
        $statement = $this->pdo->prepare('SELECT * FROM users');
        $users = $statement->fetchAll();
        return new View(
            __DIR__ . '/../../views/users.phtml',
            ['users' => $users]
        );
    }
}

views/error.phtml

<!DOCTYPE html>
<html>
<head>
    <title>Página de erro</title>
</head>
<body>
    <h1>
        Ocorreu um erro!
    </h1>

    <h2>
        #<?php echo $exception->getCode(); ?> - "<?php echo $exception->getMessage(); ?>"
    </h2>

    <?php echo $exception->getTraceAsString(); ?>
</body>
</html>

views/users.phtml

<!DOCTYPE html>
<html>
<head>
    <title>Usuários</title>
</head>
<body>
    <h1>
        Usuários
    </h1>

    <ul>
        <?php foreach ($users as $user): ?>
            <li><?php echo $user['name']; ?> - <?php echo $user['surname']; ?></li>
        <?php endforeach; ?>
    </ul>
</body>
</html>

index.php

<?php

spl_autoload_register(function ($className) {
    require __DIR__ . '/lib/' . str_replace(['\\', '_'], '/', $className) . '.php';
});

use MinimalisticFramework\ErrorDispatcher;
use App\WebErrorHandler;
use App\UserController;
use PDO;

$errorDispathcer = new ErrorDispatcher(new WebErrorHandler());
$errorDispathcer->run(function () {
    $pdo = new PDO('mysql:host=localhost;dbname=database', 'user', 'pass');

    $controller = new UserController($pdo);
    $view = $controller->getAllUsers();
    echo $view->render();
});

É evidente que isso pode ser (e será) estranho e confuso à primeira vista. Eu sugiro que você pesquise bastante sobre Separation of Concerns, S.O.L.I.D., Design Patterns e padrões da comunidade PHP (PSR-0, por exemplo). Percebo traços de código procedural e código spaghetti, mesmo que você esteja usando classes.

Ainda falta muita coisa para fazer esse código ser parecido com o mundo real. Geralmente usamos Routing, Front Controller, um Container/Sistema de configuração, etc. Nessa pegada, recomendo ler o código de frameworks bons (Zend Framework 2, Symfony2, etc.).

PS: Não testei e deve dar erro, mas o importante é o conceito.

Bruno Augusto · Outubro 14, 2013

Passei aqui só pra deixar como nota que esse código do Enrico é PHP 5.4+ :thumbsup:

Enrico Pereira · Outubro 14, 2013

Basta usar array() ao invés de [] e Closure ao invés de callable e já é compatível com o 5.3 :)

E esse código não é para produção.. é apenas um exemplo simples.

Bruno Augusto · Outubro 14, 2013

Sim, sim. É só pra não falarem que eu não tô nem aí pro tópico. :P

Outra coisa. Usar Closure como type-hinting parece que não é mais considerado uma má prática recentemente (relativamente falando). Pode ser que tenha havido algum update dentre os vários do 5.3 que tenha mudado esse comportamento

Andrey Knupp Vital · Outubro 14, 2013

➜  ~  mkdir iMasters
➜  ~  cd iMasters 
➜  iMasters  git init
Initialized empty Git repository in /home/andreyknupp/iMasters/.git/
➜  iMasters git:(master) tee config.php <<EOF
heredoc> <?php
heredoc> define( 'MYSQL_HOST', 'localhost' );
heredoc> // ...
heredoc> EOF
<?php
define( 'MYSQL_HOST', 'localhost' );
// ...
➜  iMasters git:(master) ✗ git checkout -b develop
Switched to a new branch 'develop'
➜  iMasters git:(develop) ✗ git commit -m 'Settings file ...'
[develop (root-commit) bef3632] Settings file ...
 1 file changed, 3 insertions(+)
 create mode 100644 config.php
➜  iMasters git:(develop) git branch 
* develop
➜  iMasters git:(develop) git checkout -b master
Switched to a new branch 'master'
➜  iMasters git:(master) tee config.php <<EOF
heredoc> tee config.php <<EOF             
<?php
define( 'MYSQL_HOST', '<production-host>' );    
// ...
EOF
tee config.php <<EOF
<?php
define( 'MYSQL_HOST', '<production-host>' );
// ...
➜  iMasters git:(master) ✗ git add config.php 
➜  iMasters git:(master) ✗ git commit -m 'Producting settings file ...'
[master 7f575de] Producting settings file ...
 1 file changed, 2 insertions(+), 1 deletion(-)
➜  iMasters git:(master) cat config.php 
tee config.php <<EOF
<?php
define( 'MYSQL_HOST', '<production-host>' );
// ...
➜  iMasters git:(master) git checkout develop 
Switched to branch 'develop'
➜  iMasters git:(develop) cat config.php 
<?php
define( 'MYSQL_HOST', 'localhost' );
// ...
➜  iMasters git:(develop)

Se é que me entende.

Enrico Pereira · Outubro 14, 2013

É um pouquinho de overkill para fazer o trabalho sim, concordo. Mas o problema está em si no PHP e nas inconsistências dele.. a partir daí nos temos que fazer voltas para conseguir trabalhar de uma forma decente não-gambiarrística.. se os erros do PHP fossem exceptions, metade desse código já seria desnecessário.

Henrique Barcelos · Outubro 15, 2013

Verifiquei sua classe http://henriquebarce...banco-de-dados/ e encontrei muitos erros e muitos detalhes que estão ultrapassados para desenvolvedores atualizados, não preciso entrar em detalhes porque seria anti-ético.

Ah, não se preocupe, eu aguento o tranco...

Agora, erros não têm nenhum não, funciona perfeitamente, tudo testado...

Anti-ético é soltar um comentário desses ao invés de apontar os erros, champs :thumbsup:

Bruno Augusto · Outubro 15, 2013

Coincidentemente ou não é, de certa forma, o que acabei lendo em outro artigo do Augusto a partir daquele que você passou, sobre o último framework.

O PHP é uma linguagem fantástica, mas não tem tudo o que se precisa in a box e ´por isso longe de ser perfeito.

Até mesmo esse... "desejo" de se ter os erros convertido em Exceptions é preciso fazer manualmente.

Evandro Oliveira · Outubro 15, 2013

Até mesmo esse... "desejo" de se ter os erros convertido em Exceptions é preciso fazer manualmente.

Nossa, mas não dói nadinha fazer isso, né? Sem contar que tudo ser Exception é mais fácil de se trabalhar em linguagens puramente OO.

Bruno Augusto · Outubro 15, 2013

Sim e não. Converter a grande maioria dos tipos de erro é bem fácil e, apesar de não ser difícil, outros tipos de erro (Fatal e Critical) cujos códigos são bem baixos, não são assim tão óbvios de serem capturados, via register_shutdown_function().

Tá, tá, não se deve tentar pegar esse tipo de erro e blah, blah, blah, blah, blah, mas eu gosto de uniformidade e padronização. Se todos meus erros são Exceptions e todas as Exceptions são mostradas por um handler personalizado com Template View bonitinho, então que todos os erros, sem exceção também o sejam.

Enrico Pereira · Outubro 16, 2013

O problema é que é mais complexo e menos elegante de tratar erros que não são exceptions. Não digo só por uma página bonitinha para deixar o dev feliz, mas sim por questão de logs, comunicação com o usuário e quaisquer regras de negócio no momento do erro. Se os erros forem convertidos para exceptions decentemente, é bem fácil, intuitivo e elegante manipulá-los. Isso acontece principalmente se as exceptions forem de tipos específicos (NoticeException, WarningException, etc.). Tô com umas ideias aqui relacionadas com o assunto :).

Marcelo Garbin · Outubro 16, 2013

O problema é que é mais complexo e menos elegante de tratar erros que não são exceptions. Não digo só por uma página bonitinha para deixar o dev feliz, mas sim por questão de logs, comunicação com o usuário e quaisquer regras de negócio no momento do erro. Se os erros forem convertidos para exceptions decentemente, é bem fácil, intuitivo e elegante manipulá-los. Isso acontece principalmente se as exceptions forem de tipos específicos (NoticeException, WarningException, etc.). Tô com umas ideias aqui relacionadas com o assunto :).

Pois é, isso é legal da gente discutir, eu sou meio que lunático com tratamento de dados e apresentação de erros para o usuário, tem muita coisa na internet sobre isso e muitas matérias/posts não trazem nada sobre tratamento de erros, até na universidade a gente tem muito pouco aprendizado em cima disso (quase nulo). Negócio é se virar e ver a melhor forma possível de se fazer.

Não postei mais nada aqui pois estou estudando OO, estou vendo a parte de Design Patterns agora de um curso online. Até

Bruno Augusto · Outubro 16, 2013

Nos meus códigos, hoje com alguns meses de desatualização por falta de motivação (mesmo assim se quiserem até posto um link) eu tenho um standardization concept onde através de uma ControllerException direciono os erros simples direto para o usuário.

Por ser uma padronização, o próprio sistema leva em consideração essa Exception em particular e quando ela é disparada o Dispatcher usado pelo FrontController a captura, cria uma variável de template (para ser mostrada num box pro usuário, quem sabe) e renderiza a mesma View que a do Controller que disparou a Exception.

E como todas as minhas Exceptions estendem de uma mesma classe base modificada que permite, inclusive, envio de HTTP Response Code específicos, pensando lá na frente, numa integração JavaScript.

Arquivado

Classe CRUD com PDO

Recommended Posts

Thadeu Esteves 3

Compartilhar este post

Link para o post

Compartilhar em outros sites

Evandro Oliveira 331

Compartilhar este post

Link para o post

Compartilhar em outros sites

Marcelo Garbin 30

Compartilhar este post

Link para o post

Compartilhar em outros sites

Enrico Pereira 299

Compartilhar este post

Link para o post

Compartilhar em outros sites

Marcelo Garbin 30

Compartilhar este post

Link para o post

Compartilhar em outros sites

Enrico Pereira 299

Compartilhar este post

Link para o post

Compartilhar em outros sites

Marcelo Garbin 30

Compartilhar este post

Link para o post

Compartilhar em outros sites

Enrico Pereira 299

Compartilhar este post

Link para o post

Compartilhar em outros sites

Bruno Augusto 417

Compartilhar este post

Link para o post

Compartilhar em outros sites

Enrico Pereira 299

Compartilhar este post

Link para o post

Compartilhar em outros sites

Bruno Augusto 417

Compartilhar este post

Link para o post

Compartilhar em outros sites

Andrey Knupp Vital 136

Compartilhar este post

Link para o post

Compartilhar em outros sites

Enrico Pereira 299

Compartilhar este post

Link para o post

Compartilhar em outros sites

Henrique Barcelos 290

Compartilhar este post

Link para o post

Compartilhar em outros sites

Bruno Augusto 417

Compartilhar este post

Link para o post

Compartilhar em outros sites

Evandro Oliveira 331

Compartilhar este post

Link para o post

Compartilhar em outros sites

Bruno Augusto 417

Compartilhar este post

Link para o post

Compartilhar em outros sites

Enrico Pereira 299

Compartilhar este post

Link para o post

Compartilhar em outros sites

Marcelo Garbin 30

Compartilhar este post

Link para o post

Compartilhar em outros sites

Bruno Augusto 417