Scambio di entità o ORM nel modello di repository

Question

Scambio di entità o ORM nel modello di repository

#1 da (2 voti)

0

Diciamo che sto seguendo lo schema del repository nella mia applicazione e ho

class UserEntity {

    private $model;

    public function __construct() {
        $this->model = new UserModel();
    }

}

Diciamo che questa è la mia classe di gateway tutte le cose che accadono con la roba del database è gestita da questa classe per la tabella utente

class UserModel extends eloquent {

    public function getId(){
        return $this->id;
    }
}

Questa è la mia classe userModel che attualmente utilizza ORM eloquente e supporta il massimo database. Quindi, nel prossimo futuro, se avessimo bisogno di usare doctrine o un nuovo database che questo ORM attuale non supporta, devo scambiare sia userEntities che Usermodel o userModel. E come eloquente ha i suoi metodi speciali, espongo quindi direttamente all'interno di userEntities o dovrebbe creare un gateway all'interno di UserModel?

repository-pattern repository abstraction

posta ujwal dhakal 20.06.2018 - 07:25

fonte

1 risposta

Leggi altre domande sui tag repository-pattern repository abstraction

CQRS, dovrei avere un riferimento aggregato bidirezionale? Cattura le eccezioni nel livello di servizio senza nascondere i bug

score 2 · Answer 1

Penso che il nocciolo della tua domanda sia l'agnostico del linguaggio.

Ho poca esperienza specifica per PHP qui, ma la separazione tra entità e ORM è qualcosa che ho affrontato questa settimana nel nostro progetto.

Hai ragione nell'identificare che separare l'entità dall'ORM è una buona decisione. Le tue entità definiscono la tua struttura dati, mentre il tuo ORM definisce dove (e come) memorizzare i dati. Queste sono cose separate, ed è meglio separarle (almeno nei livelli, idealmente nei progetti).

Working with C#/Entity Framework, this is very simple, since I can directly reuse the entity class as the ORM class, I don't need to redefine it. However, since you need ORM-specific logic/properties, you do need a separate ORM class to account for that. Composition, which you've used, seems to the better approach here.

Tuttavia, ho la sensazione di aver invertito il tuo approccio. Poiché la tua entità dipende dal tuo modello ORM, significa che non hai effettivamente reso la tua entità ORM-agnostica. Se cambi il tuo ORM, dovrai aggiornare le tue entità.

Pensa in questo modo: cosa succede se le tue entità sono state salvate in due posizioni di dati (utilizzando ORM diversi) allo stesso tempo? La tua entità conterrà un modello per ogni ORM. Ci saranno molte difficoltà nel decidere da dove ottenere i tuoi dati (modello A? Modello B? Verifica se sono uguali?)

Lo farei nell'altro modo: il modello contiene l'entità. Questo ha più senso, dato che avere ORM diversi avrebbe quindi un proprio modello (che contiene lo stesso oggetto Entity).
Questo ha più senso: le logiche / proprietà ORM-spefic sono semplicemente window dressing , vengono attaccate per rendere l'ORM in grado di gestire l'entità.

L'entità è il nucleo dei tuoi dati. L'ORM utilizza le entità. L'entità non utilizza l'ORM.

Ci sono diversi vantaggi in questo modo:

Una volta che il tuo ORM ha fatto il suo lavoro, devi semplicemente prendere myModel.Entity e scartare myModel stesso. Questo è l'equivalente di togliere una caramella dal suo involucro (che era solo necessario prima mangiare la barretta), perché vorrai essere in grado di gettare via l'involucro prima di mangiare ( Sarebbe sciocco se tu fossi richiesto per tenere il wrapper mentre mangi la barretta di cioccolato).
Se in seguito cambi ORM o dividi le tue entità su più ORM, il costo del passaggio è ridotto. Hai solo bisogno di cambiare il livello ORM e puoi lasciare intatto il livello Entità. Per estendere l'analogia con la barra di caramelle: se Marte vuole riprogettare i wrapper della barra di Marte, non dovrebbe essere richiesto di cambiare la barra di Mars per adattarsi al nuovo wrapper! Il nuovo wrapper deve contenere la barra esistente di Mars.