Qui andiamo sulla teoria spicciola, nel senso che ci sono mille modi diversi, ognuno con vantaggi e svantaggi. Fortuna tua che con php ce ne sono di meno.

Diciamo che i due più apprezzati sono il pattern DAO e il pattern DG, ovvero il Data Access Object e il Data Gateway. Oppure della specie di Bean che estendono VO aggiungendo metodi per la gestione del CRUD (VO = Value Object)

Dovresti decidere te quale usare. In php, dei due framework che conosco da vicino (cakephp e zend), il primo usa una specie di Bean che offre metodi crud, il secondo và di Data Gateway ( es: http://www.longacre-scm.com/blog/ind...e-data-gateway ).

Il problema ovviamente è generico, infatti stà tutto nella M dell'MVC, V e C se ne interessano poco di che pattern usi. Come è giusto che sia. Tendenzialmente M non è semplicemente "CRUD con Oggetti", ma è l'insieme delle logiche di business sfruttate poi da V e C. Nel senso che il pattern usato per la persistenza dei dati è nascosto al controller perchè il controller usa metodi e oggetti (in genere) di più alto livello.

Cmq, puoi sempre inventarti il tuo metodo per gestire il CRUD. I pattern sono linee guida, nessuno ti obbliga cmq a seguirle

Da un punto di vista personale, DAO e DG sono molto "verbosi" e tendenzialmente creano molti oggetti e interfacce (soprattutto DAO), però ti permettono di avere la logica crud separata interamente dal VO (soprattutto in DAO) e quindi usi questi oggettini stupidi stupidi che danno pochi problemi di trasporto. Il metodo Bean riduce drasticamente il numero di oggetti e interfacce da utilizzare, però accorpa la rappresentazione dei dati (VO) alla logica CRUD, e questo ha delle ripercussioni sull'uso dell'oggetto o comunque porta ad avere una classe "mista", ovvero che compie sia rappresentazione di dati che logica crud che potrebbe portare a confusione e codice poco chiaro se usata male.