È sempre carico di dati da un database un difetto di progettazione?

Question

È sempre carico di dati da un database un difetto di progettazione?

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)
#4 da (0 voti)

1

Tutti i progetti aziendali su cui lavoro sembrano seguire lo stesso schema.

Viene inviata una richiesta al server (da un client o Api)
Il lato server carica alcuni dati da un database
Modifica i dati in qualche modo
Conferma le modifiche al database

per es.

//Client after user click cancel on the order screen
_apiClient.Execute(new CancelOrder(_orderId)) ;

//On server in CancelOrderHandler
var order =_db.Orders.Single(o => o.Id == command.OrderId);
 order.Cancel();
_db.Orders.Update(order);
_db.CommitTransaction();
_db.SaveChanges();

Questo è abbastanza semplice e facile da capire, ma dato questo metodo (pattern?) è usato ovunque Mi chiedo se stiamo facendo qualcosa di sbagliato in alcuni casi?

In questo caso, potresti considerare il database come uno stato globale? Dato che 2 client possono accedere agli stessi dati nello stesso momento, anche se avrebbero istanze diverse.

Ci sono modi migliori per gestire un comando e commettere un'azione a causa di esso? O sta caricando l'ultimo oggetto di dominio da un database, cambiandolo e confermando sempre le modifiche?

design database design-patterns

posta Nick Williams 05.07.2017 - 20:07

fonte

4 risposte

Leggi altre domande sui tag design database design-patterns

Entity Framework - È una cattiva pratica lavorare con gli ID a livello di business logic? Come posso copiare e modificare l'oggetto con unique_ptr in esso?

score 1 · Answer 1

Nella progettazione di soluzioni di database client-server, il server viene riconosciuto come autorità di dati ed è il repository dei record più recenti e aggiornati relativi all'applicazione. Quindi il pattern che descrivi è ampiamente utilizzato.

La soluzione del problema dell'accesso simultaneo può essere affrontata in diversi modi. Personalmente ho usato la soluzione 'optimistic update', con una parte della clausola WHERE per l'aggiornamento che è l'ultima volta che la modifica ha letto il record del tuo cliente. Se il tuo aggiornamento non modifica alcuna riga, qualcuno ha modificato il tuo record nel frattempo e devi aggiornarlo e ricominciare.

Un altro approccio alla risoluzione di aggiornamenti quasi simultanei è un campo di stato "proprietà" e processi proprietario singleton associati che modificano il record una volta ottenuta la proprietà. Questo tipo di approccio è spesso implementato in business logic sul server web.

score 0 · Answer 2

Non necessariamente

Questa è la risposta più semplice che io penso. Lasciami spiegare.

Il modello di esecuzione in 4 passaggi .

Btw, il tuo " modello " mi ricorda il modello di unità di lavoro .

I wonder if we are doing something wrong in some cases?

Non necessariamente. Se supponiamo che lo scopo di sottostruttura di qualsiasi applicazione aziendale sia:

Raccolta dati
Elaborazione dati
Memorizza i dati
Fornisci dati

Veniamo alla conclusione che ci potrebbero essere diversi modi per raggiungere questo obiettivo. Tuttavia, le differenze saranno semplici dettagli di implementazione .

Il modello di esecuzione a 4 passaggi apparirebbe diverso nel sistema distribuito, dove le transazioni commerciali non sono sempre ACID.

I sistemi distribuiti sono la strada da percorrere? Diavolo, no!! Dipende dai bisogni.

La strada da percorrere è (o dovrebbe essere) il modo in cui funziona. La soluzione, ripetitiva o meno, dovrebbe soddisfare le tue esigenze e aspettative. Se hai trovato il pattern che funziona, (sei fortunato!), Cosa c'è di sbagliato in questo? Non appena è adeguato, le altre strategie (modelli) non contano.

La concorrenza

In this case, could you consider the database to effectively be global state? Given 2 clients could access the same data at the same time? although they would have different instances.

Non necessariamente, ma in generale sì, lo è. A meno che non si possa garantire che ci sarà un solo e unico punto di accesso al DB e nessuna concorrenza. Potresti? È possibile, ma è quello che di solito hai bisogno?

Riguardo al controllo della concorrenza . Non c'è una soluzione per proiettili d'argento. Per essere onesti, vicino al 99% dei miei progetti, la politica è LIW ( Last In Wins) . Spaventoso? Non proprio. Il controllo della concorrenza è richiesto in situazioni molto specifiche , quindi se non ne ho bisogno, perché dovrei preoccuparmi ?

Il buono, il migliore e il migliore

Are there better ways to handle a command and commit some action because of it?

No necessariamente. Non ci sono modi migliori o peggiori. Esistono diversi approcci con risultati diversi. Quello di cui hai bisogno è quello che meglio si adatta alle tue esigenze. La parola chiave qui è adequacy .

D'altra parte, forse, potresti essere interessato a modelli di design come CQRS . Ma leggi attentamente la sua adeguatezza.

score 0 · Answer 3

Or is loading the latest domain object from a database, changing it and committing the changes always the way to go?

No, non è sempre. Nel tuo esempio non è chiaro cosa sia order.Cancel() , ma se supponiamo che aggiorni solo uno stato, l'esecuzione di una procedura memorizzata che passa l'ID ordine salverebbe un sacco di attività di rete, lavoro ORM e problemi di concorrenza. Se ci sono un sacco di regole da applicare forse questo è l'approccio corretto. Dove c'è un grande numero di cose simili da fare con poca o nessuna logica di business è meglio prendere l'approccio basato sul set direttamente sul DB.

Come tutte le cose, generalmente la risposta è "dipende". Non diventare dogmatico o preso in schemi per il loro stesso interesse.

score 0 · Answer 4

> Is always loading data from a database a design flaw?

Risposta breve: No non è un difetto ma una decifrazione di desgin

Questo assunto difetto di progettazione è chiamato pattern di server stateless

Se implementi un webserver / webservice devi decidere se e quanti dati sono archiviati nella sessione per fare un compromesso tra le prestazioni (es. richiedi sempre il database) e il consumo di memoria (es. cache ultimo risultato del database)

Se le prestazioni non sono sufficienti, puoi utilizzare un servocluster (diversi server che eseguono la stessa app) o ottimizzare la memorizzazione nella cache.

Il caching può rendere l'applicazione molto più complicata / errorprone quindi è una decisione di progettazione