Ir para conteúdo

POWERED BY:

Arquivado

Este tópico foi arquivado e está fechado para novas respostas.

xKobrax

Crud Genérico

Recommended Posts

Galera, alguém conhece algum bom artigo pra me explicar como criar um Crud genérico com php Orientado a objetos,dei uma procurada e não encontrei, aliás até encontrei um bem interessante no phpbrasil mas infelizmente me parece que não está completo.Será que alguém pode me indicar um bom artigo ou tuto sobre o assunto?

 

 

 

ps:não precisa ser orientado a objetos, mas seria melhor se fosse :)

Compartilhar este post


Link para o post
Compartilhar em outros sites

Bom,acho que eu não me expressei muito bem,o que eu queria dizer é sobre a criar um crud que funcione em qualquer situação, que não precise ser alterado,só mudando a passagem de valores,como se fosse uma função,ou a classe de conexão com o banco.Um Crud que funcione para todas as operações crud de um sistema todo...tipo esse tuto aki :

 

 

só que esse infelizmente não está completo.(achei só 3pt de 5)

Compartilhar este post


Link para o post
Compartilhar em outros sites

Então amigo, ae no caso seria bom estudar algum padrão, o que geralmente o pessoal usa é o Active Record e o DataMapper já vi bastante gente usar...

Fica a seu critério, tem também os ORM's.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Eu tenho uma classe que possui os métodos select(), insert(), delete() e update() mas elas por si só não constroem o SQL e sim requisitam o SQL de um renderizador.

 

Esse renderizador, que é outra classe, é único paracada adaptador de banco de dados. A definição do objeto renderizador é abstrata, logo cada adaptador implementa a sua.

 

Algo como nos fragmentos abaixo. Removi muita coisa do que tenho de verdade, pra tentar simplificar um pouco:

 

AbstractAdapter é comum à todos os adaptadores

abstract class AbstractAdapter {

   protected $renderer;

   public function __construct() {

       $this -> renderer = $this -> setRenderer();
   }

   abstract protected function setRenderer();

   public function getRenderer() {

       return $this -> renderer;
   }
}

MySQL, dentro do respectivo namespace, é um dos muitos possíveis adaptadores

class MySQL extends AbstractAdapter {

   protected function setRenderer() {
       return new MySQLRenderer;
   }
}

método insert() com fragmento de como se usaria o renderizador definido no bloco acima.

//...
public function insert() {

   $query = $this -> getAdapter() -> getRenderer() -> insert( $this -> table, $fields );

   $this -> replacements = array_merge( array_values( $fields ), $this -> replacements );

   $stmt = $this -> execute();

   return $stmt -> lastInsertId();
}
//...

insert() a partir do Renderizador. Apenas outro fragmento, tanto que nem usa os parâmetros.

//...
public function insert( $table, array $fields ) {

   return 'INSERT INTO...';
}
//...

Dessa forma, se o projeto usar MySQL eu seto o adaptador MySQL e continuo com meus insert()'s numa boa.

 

Se, de repente eu precisar trocar para SQLITE, basta trocar o adaptador que á chamada o renderizador será refletido de acordo com a necessidade.

 

Ex: Trocar aquilo que envolve os nomes dos campos, já que a aspa única ( ' ) que é válido no MySQL faz com que os nomes das colunas sejam retornados, ao invés de seus valores, no SQLITE.

 

Veja se seria mais ou menos isso que procura.

Compartilhar este post


Link para o post
Compartilhar em outros sites

AbstractAdapter é comum à todos os adaptadores

 

Esse renderizador, que é outra classe, é único paracada adaptador de banco de dados. A definição do objeto renderizador é abstrata, logo cada adaptador implementa a sua.

 

O nome do padrão está errado.

 

Não sei o uso que você está fazendo ai, como você disse, muita coisa que você usa foi removida. Mas esse código ai (da forma que foi publicado) não é um Adapter.

 

:seta: Mas abstrair a DSL, delegando a escrita da gramática à um participante específico é uma boa pegada.

Compartilhar este post


Link para o post
Compartilhar em outros sites

AbstractAdapter é comum à todos os adaptadores

 

Esse renderizador, que é outra classe, é único paracada adaptador de banco de dados. A definição do objeto renderizador é abstrata, logo cada adaptador implementa a sua.

 

O nome do padrão está errado.

 

Não sei o uso que você está fazendo ai, como você disse, muita coisa que você usa foi removida. Mas esse código ai (da forma que foi publicado) não é um Adapter.

Então, pelo amor de Deus, me fala como esse ngócio se chama. :lol:

 

Tudo quanto é lugar que li, só caía Adapter, Adapter, Adapter... :P

 

:seta: Mas abstrair a DSL, delegando a escrita da gramática à um participante específico é uma boa pegada.

:grin:

 

Indiretamente, aprendi contigo ^_^

Compartilhar este post


Link para o post
Compartilhar em outros sites

Começei a estudar Design Patterns faz pouco tempo, mas vou dar a cara a tapa.

O Pattern Adapter serve para converter a interface de uma classe em outra interface.

<?php

abstract class Conector
{
    abstract function pinoPositivo( );
    abstract function pinoNegativo( );
}

class Conector3Pinos extends Conector
{
    public function pinoPositivo( )
    {
        return 'Pino Positivo';
    }
    public function pinoNegativo( )
    {
        return 'Pino Negativo';
    }
    public function pinoTerra( )
    {
        return 'Pino Terra';
    }
}

class Conector2Pinos extends Conector
{
    public function pinoPositivo( )
    {
        return 'Pino Positivo';
    }
    public function pinoNegativo( )
    {
       return 'Pino Negativo';
    }
}

class AdapterConector3Pinos extends Conector3Pinos
{
    private $conector;

    public function __construct( Conector $conector )
    {
        $this->conector = $conector;
    }
    public function pinoPositivo( )
    {
        return $this->conector->pinoPositivo( );
    }
    public function pinoNegativo( )
    {
        return $this->conector->pinoNegativo( );
    }
    public function pinoTerra( )
    {
        return 'Pino Terra';
    }
}

class Tomada3Pinos
{
    private $conector3Pinos;

    public function __construct( Conector3Pinos $conector3Pinos )
    {
        $this->conector3Pinos = $conector3Pinos;
    }
    public function conectar( )
    {
        printf( '%s conectado<br/>%s conectado<br/>%s conectado<br/>',
        $this->conector3Pinos->pinoPositivo( ), $this->conector3Pinos->pinoNegativo( ), $this->conector3Pinos->pinoTerra( ) );
    }
}

$conector1 = new Conector3Pinos;
$tomada1 = new Tomada3Pinos( $conector1 );
$tomada1->conectar( );

echo '<hr>';

$conector2 = new Conector2Pinos;
$adaptadorPara3Pinos = new AdapterConector3Pinos( $conector2 );
$tomada2 = new Tomada3Pinos( $adaptadorPara3Pinos );
$tomada2->conectar( );

?>

 

 

Saída

Pino Positivo conectado
Pino Negativo conectado
Pino Terra conectado
------------------------
Pino Positivo conectado
Pino Negativo conectado
Pino Terra conectado

Compartilhar este post


Link para o post
Compartilhar em outros sites

Tá certo que não entendo muito mas, se for isso mesmo, não parece gambiarra? Tipo uma implementação pra remendar uma coisinha antes impessada?

Compartilhar este post


Link para o post
Compartilhar em outros sites

Acho que a idéia do adaptador não é bem essa, eu acho que é o seguinte, sua aplicação pode rodar em 3 bancos de dados, sendo MySQL, Postgre, Firebird .. então, em algum momento, você poderia fazer uma troca do banco atual pro firebird, sem ter que precisar alterar toda dsn e afins, mas sim, alterando um ini, ou um resources bundle .. tanto faz, nesse caso, você já iria pegar o adaptador para o firebird, e trocar todo o esquema do banco, é o que o método getDefaultAdapter representa, então você teria uma classe que pode retornar várias conexões com vários sgbd's, e nessa classe, pegando o adaptador padrão.

Compartilhar este post


Link para o post
Compartilhar em outros sites

O interessante é que ele cria uma abstração intermediária que "traduz" o componente antigo para um novo sistema.

 

Sobre banco de dados:

Seria criar um adaptador para interceptar as chamadas de métodos relacionados ao banco de dados antigo e fazer aqueles compatíveis com o novo banco de dados.

 

Deixo a palavra com os mais experientes :D

Compartilhar este post


Link para o post
Compartilhar em outros sites

O Pattern Adapter serve para converter a interface de uma classe em outra interface.

 

:yes: Isso, Adapter converte uma interface em uma outra interface e permite que classes que seriam incompatíveis trabalhem juntas.

 

Tá certo que não entendo muito mas, se for isso mesmo, não parece gambiarra? Tipo uma implementação pra remendar uma coisinha antes impessada?

 

Remendar é um termo totalmente equivocado, você vai adaptar, não remendar.

 

1. Uma classe já existe em um sistema.

2. Você vai implementar uma nova feature.

3. Na nova feature, um client depende de uma funcionalidade X existente e de uma funcionalidade Y nova.

 

Se você reimplementar a funcionalidade X, você terá problemas futuros de manutenção (haverão dois lugares com mesmo code para manter => POG).

 

Se você mudar o código existente que implementa a funcionalidade X, você estará violando O.C.P., I.S.P. e, muito possivelmente, S.R.P.. Sem contar que terá que fazer todos os testes nos clients que utilizam a classe modificada e poderá criar bugs em sistema já homologado.

 

Se você tiver uma família inteira de subclasses, pode ser inviável derivá-las, uma a uma, para se implementar uma nova funcionalidade.

 

:seta: Quando você precisa reutilizar código existente (muitas vezes, uma família inteira de subclasses) que possui uma interface diferente daquela que você precisa, você pode utilizar Adapter.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Deixa eu ver se eu entendi.

 

Essa AbstractAdapter que eu citei, no meu caso, implementa uma interface IAdapter que é usada como type-hint de um Registry de adaptadores de Banco de Dados.

 

Qualquer classe que extenda essa uma, pode ser usada como link de conexão.

 

Porém, temos a PDO. Os drivers da PDO têm, a exemplo, uma coisa "a mais" que os outros não tem (ou podem não ter) e que ainda são (ou podem ser) ligeiramente diferentes entre si: Os DSN's.

 

Então, existe uma classe intermediária, AbstractPDO, que extende a anteriormente citada porém adiciona um método abstrato getDSN().

 

Sendo assim, cada implementação de cada driver (que é onde entram os renderizadores que eu disse), ao invés de extender AbstractAdapter, extendem AbstracPDO e continuam sendo instâncias de IAdapter.

 

Essa "camada do meio" seria, de fato, um Adaptaer, não?

Compartilhar este post


Link para o post
Compartilhar em outros sites

Deixa eu ver se eu entendi.

 

...a exemplo, uma coisa "a mais" que os outros não tem (ou podem não ter) e que ainda são (ou podem ser) ligeiramente diferentes entre si: Os DSN's.

 

:hehehe: Eu sei que você entende aquilo que você pensa que eu digo. O que não sei, é se você percebe que aquilo que você entende não é aquilo que você pensa que eu digo.

 

Bruno, o exemplo da tomada e conector do Carlos é perfeito :seta: Se você tiver no seu code uma tomada para dois pinos e um conector com três pinos, use um Adapter para que a tomada e o conector possam trabalhar juntos.

 

;)

Compartilhar este post


Link para o post
Compartilhar em outros sites

@BrunoAugusto e @Andrey, vcs estão usando um pattern para um problema que vcs não tem.

Por isso estão arranjando outro problema.

 

Esqueça essa de Adaptar para MySQL, PostGree... e tb o PDO. No caso, não é para isso que existe o Adapter, então não é nesse momento que vcs devem utiliza-lo.

Compartilhar este post


Link para o post
Compartilhar em outros sites

veio, procure sobre o query object pattern...

 

O Query Object é uma variação de Interpreter Design Pattern (GoF)

 

Pesquisar pelos dois trará um bom conhecimento para alcançar esse objetivo.

 

;)

Compartilhar este post


Link para o post
Compartilhar em outros sites

Deixa eu ver se eu entendi.

 

...a exemplo, uma coisa "a mais" que os outros não tem (ou podem não ter) e que ainda são (ou podem ser) ligeiramente diferentes entre si: Os DSN's.

 

:hehehe: Eu sei que você entende aquilo que você pensa que eu digo. O que não sei, é se você percebe que aquilo que você entende não é aquilo que você pensa que eu digo.

Maldade. Agora você me confundiu de vez.

 

Bruno, o exemplo da tomada e conector do Carlos é perfeito :seta: Se você tiver no seu code uma tomada para dois pinos e um conector com três pinos, use um Adapter para que a tomada e o conector possam trabalhar juntos.

 

;)

Então, pelo que percebi, eu entendi certo.

Compartilhar este post


Link para o post
Compartilhar em outros sites
Eu sei que você entende aquilo que você pensa que eu digo. O que não sei, é se você percebe que aquilo que você entende não é aquilo que você pensa que eu digo.
Então, pelo que percebi, eu entendi certo.

uahsuahshuas =p

srry pelo flood

Compartilhar este post


Link para o post
Compartilhar em outros sites

×

Informação importante

Ao usar o fórum, você concorda com nossos Termos e condições.