DB Ritorni di aggiornamento delle entità nel modello di repository

Question

DB Ritorni di aggiornamento delle entità nel modello di repository

#1 da (1 voti)
#2 da (1 voti)

1

Sto cercando di avvolgere la mia mente attorno a OOP quando costruisci sistemi CRUD semplici, usando il Pattern del repository per gestire il recupero / salvataggio degli oggetti nella memoria persistente.

Ho già progettato e implementato un sistema che non utilizza OOP, ma solo per ottenere, inserire, aggiornare ed eliminare funzioni che contengono query SQL.

Modo non OOP

Ad esempio, per l'aggiornamento di un cliente chiamerei questa funzione:

// PUT customer
function updateCustomer(idCustomer, data) {
  db("customer").update(data).where("idCustomer", idCustomer);
}

Modo OOP

Ora, per implementarlo in OOP utilizzando il schema del repository farei qualcosa del tipo:

// PUT customer
customer = customerRepo.getById(idCustomer);
customer.setData(data);
customerRepo.update(customer);

La modalità OOP sembra richiedere un extra round di DB

Questo modello di OOP sembra richiedere i roundtrip di DB dal momento che è necessario:

Crea un'istanza di un nuovo oggetto cliente dal DB utilizzando il repository
Aggiorna i dati nell'oggetto
Salva l'oggetto nel DB utilizzando il repository

Domanda

Il mio attuale modo di non fare OOP non è più efficiente? Se sì, ci sono soluzioni comuni a questi roundtrip quando si segue il 2o metodo OOP?

object-oriented

posta Nik Kyriakides 04.05.2017 - 02:48

fonte

2 risposte

Leggi altre domande sui tag object-oriented

Utilizza casi senza attori primari Esistono validi motivi per modificare il codice di un'applicazione tra build e release?

score 1 · Answer 1

Questo non è giusto. Stai confrontando due cose diverse. Un metodo più giusto e perfettamente uguale per il secondo esempio potrebbe essere:

// PUT customer
customer = Customer();
customer.setId(customerId);
customer.setData(data);
customerRepo.update(customer);

E in questo scenario, stai anche solo facendo una query (l'aggiornamento) ma è ancora più orientata agli oggetti. Il tuo problema è che stai creando un argomento "pagliaccio", suggerendo che ottenere il cliente dal database prima sia in qualche modo intrinseco all'orientamento all'oggetto e al modello, ma non è vero. OOP, i repository e se ottenere o meno i dati dal database non hanno prima nulla a che fare l'uno con l'altro.

score 1 · Answer 2

Credo che per il più semplice dei modelli CRUD, anche il Repository è un overkill.

Lo scopo principale del modello di repository è quello di consentire di interrogare il modello di oggetti ricchi, che può quindi essere manipolato in modo OOP. Questo sacrifica alcune query DB per acquisire la capacità di manipolare i dati in un modo "migliore" rispetto al semplice SQL.

Ma nel tuo caso, sembra che non ci sia bisogno di un modello di dominio ricco, dato che sembra funzionare bene con SQL semplice.