Mantendo um modelo MVC fracamente acoplado ao DB?

Eu gosto de manter meu código testável e decidi seguir a estratégia de injeção de dependência para minha estrutura MVC atual, que definitivamente provou ser uma ótima maneira de garantir código, testabilidade e modularidade fracamente acoplados.

Mas, por estar longe de ser um mestre nos padrões de design, tenho dificuldade em descobrir uma boa maneira de manter meus modelos tão fracamente acoplados das classes de conectores do banco de dados quanto possível.

Como isso pode ser feito?
Como não forneci nenhum código físico junto com essa pergunta, eu realmente aprecio alguns exemplos ou informações de lógica / código que podem me indicar uma direção para entender o problema descrito acima.

Uma maneira é projetar seus modelos antes de projetar seu banco de dados. Ao projetar seus modelos, o foco é capturar a lógica e os significados do negócio no domínio do problema. Isso deve ser capturado de uma maneira que faça sentido para os negócios, incluindo mais do que apenas entidades e campos de dados. Alguns elementos de dados são interpretados por outros, outros dependem de outros etc. Além disso, você adicionaria a este modelo qualquer lógica básica necessária, como a forma como um objeto responde internamente quando um determinado elemento é definido com um determinado valor.

É bem provável que você termine com algo 90% mais idêntico ao de como você mantém os dados. Isso é bom. Pode ser completamente idêntico sem ser acoplado.

Observe também que modelar o domínio em meio a uma verdadeira ignorância de persistência é um pouco do santo graal para o design de software. Se você pode fazer isso, fantástico. Mas se o domínio do problema é significativo e tem alguma complexidade, ainda é uma boa idéia voltar da modelagem de domínio de tempos em tempos para fazer uma verificação de integridade na persistência dos dados para garantir que você não tenha pintado -se em um canto.

Lembre-se das funções reais dos vários componentes e mantenha-as separadas quando as projetar. Para qualquer decisão de design, pergunte-se se alguma dessas funções é violada:

1. Banco de dados - armazene os dados, mantenha a integridade dos dados, mantenha os dados em repouso.
2. Modelos - Conter a lógica de negócios, modelar o domínio do problema, manter os dados em movimento, responder a eventos em nível de negócios etc.
3. Exibições - Apresente dados aos usuários, execute a lógica do lado do usuário (validação básica antes da validação verdadeira nos modelos, etc.).
4. Controladores - responda a eventos do usuário, passe o controle para modelos, direcione solicitações e retorne respostas.

Você quer ter duas coisas.

1. Seus modelos (acessadores do DBAL e fazendo a maior parte da lógica do aplicativo).

2. Seus "Modelos de Domínio", também conhecidos como Entidades de Dados, representam as entidades do seu sistema, como usuários, postagens, produtos etc.

   class PPI_Model_User {
   
       protected $_conn = null;
   
       function __construct(array $options = array()) {
           if(isset($options['dsnData'])) {
               $this->_conn = new PPI_DataSource_PDO($options['dsnData']);
           }
       }
   
       function getAll() {
           $rows = $this->_connect->query("SELECT .....")->fetchAll();
           $users = array();
           foreach($rows as $row) {
               $users[] = new PPI_Entity_User($row);
           }
           return $users;
       }
   
   }
   

Código de uso

    $model = new PPI_Model_User(array('dsnData' => $dsnData));
    $users = $model->getAll();
    foreach($users as $user) {
        echo $user->getFirstName();
    }

Aí está, é assim que você cria modelos de domínio (Entidades) e tem modelos MVC fazendo a conectividade do DB e a manipulação de dados.

Se você está se perguntando o que é PPI, pesquise no Google por "PPI Framework".

Boa sorte com sua pesquisa.

Atenciosamente, Paul Dragoonis.

Lembre-se, o MVC surgiu em smalltalk, que tem persistência automática para todos os objetos. Portanto, o padrão MVC não prescreve nenhuma solução para separação de modelo / persistência.

Minha preferência é fornecer um objeto "Repositório" que saiba como criar objetos Model a partir do banco de dados e armazenar objetos Model no banco de dados. Então o modelo não sabe nada sobre persistência. Algumas ações do usuário terão que ativar um salvamento, portanto, é provável que o Controlador conheça o Repositório. Normalmente, uso alguma forma de injeção de dependência para impedir que o controlador seja acoplado ao repositório.