Como estender este simples DataMapper?

Question

Alguém por favor pode derivar um exemplo concreto a partir do seguinte:

http://www.urdalen.com/blog/?p=210

.. que mostra como lidar com one-to-many e many-to-many relacionamentos?

Eu enviei um email ao autor algum tempo atrás, mas não recebeu resposta. Eu gosto de sua ideia, mas não consigo descobrir como implementá-lo além das relações única tabela simples.

Nota: Eu não quero usar um ORM full-blown. Eu gosto de fazer o meu SQL à mão. Eu gostaria de melhorar o design do meu código do aplicativo embora. Agora cada objeto de domínio tem a sua própria classe cheia de consultas embrulhados em métodos estáticos. Eles só voltar escalar, 1d-array (registro) ou 2d-array (registros), dependendo da consulta.

Answer 1

O problema da ORM de (A diferença de impedância, como é chamado) é precisamente com as relações. Em um gráfico de objeto (objetos em memória), os relacionamentos são ponteiros para outros objetos. Em um banco de dados relacional, as relações são invertidas; Isso torna impossível fazer um mapeamento simples entre os dois modelos, e é por isso ORM são tão complexos.

Se você quiser ficar perto do banco de dados (evitando um ORM), então você não deve tentar relações abstratas de distância. A forma como eu escrevo datamappers é algo como o seguinte:

$car42 = $car_gateway->fetch(42);
$wheels = $wheel_gateway->selectByCar($car42);

Em contraste com a maneira ORM:

$car42 = $car_gateway->fetch(42);
$wheels = $car42->selectWheels();

Este significa que os gateways acabar em seu cliente-código, mas também mantém as coisas muito transparentes e perto do banco de dados.

Answer 2

Se você está procurando um simples e portátil DataMapper ORM, ter um olhar para phpDataMapper . É apenas dependências são PHP5 e DOP, e é muito pequeno e leve. Ele suporta relações de mesa e algumas outras características muito agradáveis ??também.

Answer 3

Dada a sua resposta a resposta de Tom, eu recomendo que você olhar para algo como Zend Framework. Sua ORM tem um tomá-lo ou deixá-lo arquitetura que pode ser implementado em etapas.

Quando eu vim para o meu empregador atual, eles tinham um aplicativo que tinha acabado de ser concluída meses anteriormente, mas tinha sido através de uma ou duas versões anteriores ea versão atual tinha sido no desenvolvimento de seis meses a mais do que era suposto ter sido. No entanto, a base de código foi confusão. Por exemplo, houve nenhuma abstração entre a lógica de acesso a banco de dados e lógica de negócios. E, eles me queria mudar o local para a frente a construção de uma nova funcionalidade, estendendo os recursos existentes, e corrigir bugs existentes no código. Para complicar ainda mais as coisas que eles não estavam usando qualquer forma de saneamento sobre entradas ou saídas de dados.

Quando comecei a percorrer para o problema, eu percebi que eu precisaria de uma solução para as preocupações abstratos que poderiam ser implementadas em etapas, porque eles, obviamente, não estava indo para ir para uma reescrita completa. Minha abordagem inicial era escrever um ORM personalizada e DAL que iria fazer o trabalho pesado para mim. Ele trabalhou muito, porque ele não intrometer na base de código existente, e por isso me permitiu mover porções inteiras da aplicação para a nova arquitectura de uma forma discreta.

No entanto, depois de ter portado uma grande parte da área do usuário do nosso site a esta nova estrutura e ter construído um aplicativo inteiro no meu quadro personalizado (que passou a incluir também um controlador personalizado front-end e implementação MVC), estou mudando para Zend Framework (esta é a minha escolha embora estou certo de que alguns dos outros frameworks também iria trabalhar nesta situação).

Na mudança para o Zend Framework Não tenho absolutamente sem preocupações sobre a base de código legado, porque:

• eu posso construir novos modelos e refatorar modelos antigos (construídos em meu costume framework) de forma discreta.
• posso refatorar o existente controladores (tal como eles são) para ser envolto dentro de uma classe que comporta de uma maneira consistente com o Zend de framework MVC para que se torne um questão menor para começar realmente usando Front-End do Zend Controller.
• Nossos pontos de vista já são construídos em Smarty por isso não precisa se preocupar sobre a separação e controlador de vista lógica, mas vou ser capaz de estender o Zend Framework para que eu possa renderizar os modelos existentes em Smarty enquanto a construção de novos modelos no PHP em linha reta.

Basicamente, Zend Framework tem um pegar ou largar arquitetura que faz sua uma alegria para utilização no âmbito de projectos existentes, porque o novo código e código refatorado não precisa de se intrometer em código existente.