Ho lavorato su diversi sistemi di ordinazione. Ognuno di loro ha tracciato la spedizione e la gestione come parte dell'intestazione dell'ordine piuttosto che rilevarlo come un elemento pubblicitario. Per me, avrebbe più senso tenerli con gli elementi pubblicitari, anche se le informazioni non vengono visualizzate in questo modo all'utente. Quali sono i motivi per tenerli nell'intestazione?
Lascia che ti chieda questo. Se ordino 100 articoli e poi cambi idea e chiedo di avere solo 50 prima che l'oggetto venga spedito, la spedizione diminuirà? In altre parole, la spedizione di un addebito per ordine che non cambierà indipendentemente da ciò che viene ordinato o è calcolato in base ai singoli articoli nell'ordine. Se spedisci oggetti pesanti, è probabile che sia basato sugli articoli ordinati e quindi conservati lì. Se spedisci oggetti più leggeri, probabilmente l'addebito è standard per ordine e dovrebbe essere memorizzato nella tabella principale.
Penso che il ragionamento sia duplice per il collocamento di spedizione, gestione, tasse, ecc. come campi calcolati sull'intestazione.
Gli sviluppatori potrebbero preferire questo stile, avendo lavorato in applicazioni legacy ho notato che molti sviluppatori a partire dalla metà degli anni '90 tendevano a utilizzare un design di tabella piatto con campi calcolati.
I progettisti del software potrebbero non essere consapevoli di utilizzare un approccio più normalizzato alla progettazione del software specificamente nel dominio. Se stavo presentando un'esecuzione della fresatrice UI Shipping, Hanlding, Tax, sono generalmente valori sommati visualizzati come parte del processo di totalizzazione dell'ordine.
Conseguentemente gli autori del codice non distinguono tra un modello di dominio e un modello di vista o l'aspetto della vista del modello di dominio. Supponendo che i due siano strettamente accoppiati è comprensibile.
Se dovessi esprimere la mia opinione su quale sia il percorso migliore, sceglierei un approccio normalizzato per fornire le spese di spedizione, gestione, tasse e altri costi come elementi pubblicitari per ridurre i campi calcolati nell'intestazione dell'ordine. Quindi li fornirei come valore di somma in un ViewModel se necessario, ma solo come un prodotto della visualizzazione dell'interfaccia utente mai come metodo di archiviazione dei dati.
Pensa in questo modo: un singolo ordine di spedizione spedisce più articoli in un unico indirizzo. Da quella semplice frase è possibile dedurre le relazioni di entità tra i vari bit di dati. Un ordine di spedizione ha una relazione uno-a-molti con gli articoli, quindi il modulo dettagli principali. D'altra parte, un ordine di spedizione ha una relazione uno-a-uno con l'indirizzo di spedizione, quindi fanno parte della stessa forma e in un DB normalizzato faranno parte della stessa tabella.
Leggi altre domande sui tag data