Class de 'Conexão'

[uiLhian 1]

;(

[Enrico Pereira 299]

E existe uma terceira alternativa?

 

Controlar instâncias :)

[Bruno Augusto 417]

Controlar instâncias :)

 

Isso não explica o seu posicionamento contra o Registry. Como que a Aplicação determinada pelo FrontController, que é quem deveria efetuar a conexão com o banco perpetuaria o link pelo fluxo da Requisição em forma de objeto até que a model possa utilizá-lo?

 

Eu vejo que injetar o objeto de conexão como dependência na(s) Model(s) é uma prática ruim pois deixaria múltiplas conexões "soltas" pelos Controllers ou mesmo pelas Models.

 

Se bem que traria como benefício conectar ao banco apenas quando e se necessário, mas isso é perfeitamente controlável pela interface do Driver adaptador.

[Henrique Barcelos 290]

Outra parte do código, injete o Db_Driver, não acesse nunca, tenha uma camada de serviços com um Container, veja como isso é ruim:

 

<?php

class UserAccess
{
    public function __construct(Db_Driver $driver)
    {
        // ..
        // eu posso mudar a conexão, isso mata esse "defaultDriver", eu tenho controle sobre o que não deveria ter. Se eu usar um objeto representando uma conexão isso não seria problema, eu não conheceria a conexão e nem mesmo poderia mudá-la.
    }
}
// Para usar
$driver = new Db_Driver(new Mysqli(etc));
$access = new UserAccess($driver);

Não entendi a sua colocação. Se eu altero a conexão, obviamente, vou deixar de fazer uso do defaultDriver, mas ele continua lá para novos objetos Db_Driver instanciados sem uma conexão no construtor.

 

Acho que seria de grande utilidade você mostrar como "controlar instâncias", pois acho que ninguém aqui entendeu o que vc quis dizer.

[Enrico Pereira 299]

Mas acho que você não deve fazer dessa forma, acho que o correto é um objeto representando uma conexão, não vejo forma melhor.

 

Controlar instâncias, saber manusear objetos, até pode usar Registry, mas com moderação veja bem:

 

Forma horrorosa:

 

<?php
class DataAccess
{
    public function __construct()
    {
        $this->conn = Registry::get('db');
    }
}

// usando

$da = new DataAccess;

 

 

- Acoplado ao Registry

- Para saber as dependências você necessita, você precisa ler o código

- Não muito testável, convenhamos

 

Forma ruim:

 

<?php

class DataAccess
{
    public function __construct(Registry $r)
    {
        $this->conn = $r->get('db');
    }
}

// usando

$da = new DataAccess(Registry::getInstance());

 

 

 

- Acoplado a implementação de registry

- Singleton

- Para saber as dependências você necessita, você precisa ler o código

- Não muito testável, convenhamos

 

Forma regular:

 

<?php

class DataAccess
{
    public function __construct(RegistryInterface $r)
    {
        $this->conn = $r->get('db');
    }
}

// usando

$da = new DataAccess(Registry::getInstance());

 

 

- Singleton

- Para saber as dependências você necessita, você precisa ler o código

- Não muito testável, convenhamos

 

Forma mediana:

 

 

<?php

class DataAccess
{
    public function __construct(RegistryInterface $r)
    {
        $this->conn = $r->get('db');
    }
}

// usando

// Registry não é mais singleton, projete o FrontController para injetar o Registry em algum lugar (classe de Bootstrap, etc)

$registry = new Registry;
$registry->set('db', $db);

$da = new DataAccess($registry);

 

 

- Para saber as dependências você necessita, você precisa ler o código

 

Forma boa:

 

<?php

class DataAccess
{
    public function __construct(DatabaseInterface $conn)
    {
        $this->conn = $conn;
    }
}

// usando

// Registry não é mais singleton, projete o FrontController para injetar o Registry em algum lugar (classe de Bootstrap, etc)

$registry = new Registry;
$registry->set('db', $db);

$da = new DataAccess($registry->get('db'));

- Para saber as dependências você necessita apenas ver a API do objeto :clap:

 

Acho que a partir daí um Dependency Injection Container seria muito mais útil e faria mais sentido.

[Bruno Augusto 417]

Não tem muita diferença entre o último e o primeiro código, o que rolou aí, pelo que eu pude entender, foi respeitar o S (do SOLID) através de uma DI, ao invés de associar na Model, injetou pelo Controller.

 

De todo jeito não deixou-se de lado o Registry, logo a sua objeção sobre ele em particular ainda não foi justificada.

 

Ah! E que conste nos autos do processo, desde sempre eu fazia certo e não sabia. o.O

[Enrico Pereira 299]

Mudou sim! O código ficou altamente testável e desacoplado de um Registry, ele só é usado para implementação, veja o Zend Framework 2, o Symfony 2, o Silex, o Slim, nenhum deles usa singleton/registry (o zf2 até usa em classes separadas para isso, comunidade ainda não se curou da singletonite).

 

Sobre o Registry, acho que isso nem seria muito mais registry, penso que DIC seria melhor, arquitetura Hollywood conseguimos comunicar objetos sem precisar de os chamar com singleton ou registry.

 

Nessa forma, é muito mais produtiva e vc foca primeiro na sua lógica, nas suas libs, etc. vc não programa orientado a framework, usa bibliotecas do framework/externas/suas e depois implementa com o "core" do framework, as rotas, configs, etc.

[Henrique Barcelos 290]

É uma forma perfeitamente válida também, e, na essência, o intuito é o mesmo, o resultado é bem parecido com o que eu mostrei. A diferença é que aí envolve mais componentes, o que pode acabar confundindo um iniciante, mesmo sendo algo muito simples.

[Enrico Pereira 299]

É uma forma perfeitamente válida também, e, na essência, o intuito é o mesmo, o resultado é bem parecido com o que eu mostrei. A diferença é que aí envolve mais componentes, o que pode acabar confundindo um iniciante, mesmo sendo algo muito simples.

 

Concordo plenamente, mas alguma vez ele precisa aprender, só vai aprender batendo cabeça.

[Bruno Augusto 417]

Eu ainda estou com uma certa dificuldade em ver um Registry sem Singleton numa aplicação real.

 

Meu cenário hoje é:

 

Através do .htaccess direcionar a requisição para um Bootstrap, À parte de todo bê-a-bá que este faz, informa ao FrontController as Aplicações disponíveis para trabalhar.

 

O FrontController itera pelas aplicações, determinando, através do Router associado à cada Aplicação, quem é o Action Controller responsável pela requisição e o despacha. Durante esse procedimento recursos são configurados, dentre eles os links de conexão.

 

E é aí que eu quero chegar. Até chegar no Action Controller, que é onde efetivamente se programa, é tudo automático, sem instâncias manuais.

 

E mesmo com o fluxo da requisição sendo vertical e crescente, o PHP é limitado pelo escopo das variáveis. Como que o link do objeto de conexão entraria no Action Controller? Variável Globais :sick:

[Enrico Pereira 299]

Veja a implementação de Controller do Zend Framework 2.

 

Exemplo bom: https://github.com/Bacon/BaconLiquibase