Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Com base nessa resposta do Henrique Barcelos, acho que consegui compreender a motivação do RowDataGateway.
Mas eu não estou conseguindo implementá-lo.
Eu optei por centralizar as operações de CRUD num Gerenciador de Tabela. Com ele, consigo fazer um SELECT simples em três linhas:
$em = new DB\Table\Manager( new Models\SomeTable( $conn ) );
$em -> select() -> from( array( 'sometable' ) );
var_dump( $em -> fetchAll() );
Desconsiderando como $conn é criado, claro ;)
Mas não sei exatamente onde o RowDataGateway deveria entrar. Seria nos método que trazem os dados de volta, no meu caso, fetch() e fetchAll()?
Pelo sim e pelo não, meu Gerenciador é construído com uma instância de Table, que além de receber a conexão como mostrado acima, tem alguns accessors, dentre eles um que me retorna as propriedades dinamicamente criadas (com __set)
Supondo que o RowDataGateway entre no fetch() (um único registro) e eu queira fazer um UPDATE, como eu passaria para meu Gerenciador uma instância de Row se ele espera Table?
Será que eu deveria ter não ter uma classe Row e sim popular diretamente a própria Table?
Do jeito que eu fiz todas as operações básicas funcionam perfeitamente, mas esse comentário me deixou meio receoso de estar fazendo errado.
E pra variar, não entendo o que Martin Fowler escreve. <_<
Carregando comentários...