Trattare con la personalizzazione delle entità

Naviga le tue risposte
1

Suppongo che ogni progetto considerato enorme e diversificato in un sacco di parti (lato amministratore, widget, API, sito Web con un sacco di roba e gestione) possa finalmente incontrare che è davvero difficile usarne solo uno o più entità di qualche tipo ovunque. Per esempio. prendiamo booking entità in azione. Abbiamo alcune entità generali che hanno tutte le informazioni necessarie in realtà, ma da qualche parte abbiamo bisogno di essere abbreviate o riempite con un'entità di informazioni aggiuntive per non modificare l'entità esistente. Ecco alcuni esempi dettagliati:

Entità prenotazione:

  • id
  • nome
  • tipo di pagamento

Esteso con informazioni dettagliate sul pagamento:

  • id
  • nome
  • raccolta dei dati relativi al tipo di pagamento (data in cui è stato effettuato / confermato / cancellato ecc., nome dell'acquirente, quantità di articoli acquistati, ecc.)

... e molti altri ancora

Qual è il modo più logico per affrontarlo? Creare molte entità per soddisfare meglio ogni caso o rendere l'entità di base estendibile in qualche modo?

Aggiornamento 1: La vera domanda non riguarda la convalida dei campi o qualcosa del genere. La domanda riguarda la situazione quando si hanno molte entità simili per scopi diversi e come si gestiscono queste cose in genere.

    
posta Grokking 22.05.2017 - 11:22
fonte

2 risposte

1

Vorrei separare paymentinfo / deliveryinfo / customerInfo / .... dalla prenotazione / dall'ordinazione.

vantaggi:

  • puoi gestire l'uso di hasNotPayedYet (la prenotazione non ha alcun pagamento)
  • puoi gestire i versamenti da utilizzare (l'80% deve essere pagato 14 giorni dopo la prenotazione, il resto 2 settimane prima dell'inizio del viaggio)
  • puoi modificare i dettagli dell'implementazione dei pagamenti senza influire sugli altri modul.
    • esempio puoi in un secondo momento aggiungere altri tipi di pagamento diversi (ad es. carta di credito, pay-on-delivery, paypal, advance, ....) con i loro campi specifici.
risposta data 22.08.2017 - 10:52
fonte
0

Il modo più logico per occuparsi di questo ha a che fare con le risposte a queste domande:

Cosa succede se l'entità di prenotazione ha un nome, un nome dell'acquirente, ma nessuna data? Cosa succede se manca il nome dell'acquirente? Una stringa vuota è un nome valido? Che ne dici di un trattino?

Non vedo il caso per i tipi fatti qui. Se ci avessi detto il modo diverso in cui queste diverse entità sarebbero state usate forse potrei vederlo. Potresti avere una situazione in cui desideri convalidare i dati in modo diverso, ma non abbiamo un solo buon indicatore di quando.

Le domande di acido da chiedere qui: quando questi valori non sono forniti hai dei buoni valori di default per loro? Che valore è veramente richiesto?

    
risposta data 22.05.2017 - 15:00
fonte

Leggi altre domande sui tag

MS SSIS come buon approccio per la sincronizzazione dei dati a due vie I controller di visualizzazione iOS e il loro metodo viewDidLoad violano il principio di responsabilità singola?