Aggiornamento di entità nidificate con vincoli senza ottenere spaghettimadnessità

0

Ho un "nodo" di endpoint che dovrebbe accettare un'entità. Questa entità può contenere diverse sub-entità con ancora alcune sub-entità. Poiché si tratta di un endpoint di "importazione", alcune delle entità o sub-entità possono esistere dalle importazioni precedenti, alcune potrebbero non esserlo, altre sono obbligatorie e altre no. Alcuni hanno regole speciali (ex email non può essere duplicata dell'email di altre entità) e così via.

Esiste una tecnica, un pattern o un algoritmo che rende questo codice più semplice da scrivere in modo pulito? Ogni volta che c'è un bug in questa logica dobbiamo aggiungere un altro o più "se" e sta diventando piuttosto fuori controllo.

Sto pensando; questo è fondamentalmente un albero con regole in alcuni nodi e foglie. Ci potrebbe essere qualcosa di intelligente là fuori che non lo sappiamo.

Potrebbe non essere importante, ma questa è un'API Web ASP.Net con Enity Framework che funge da ORM verso un database relazionale SQL

Aggiornamento 1

Questa è una bozza di ciò che sto trattando strutturalmente.

L'importazione riceve un elenco di utenti con tutte le subentità collegate.

{
  users:[
    {
      prop1: value1,
      prop2: value2,
      company 
      {
        prop1: value1
      },
      ...,
    },{..}
  ]
}

Tutte le entità in questa struttura hanno diverse proprietà di tipo valore. Con la funzione di importazione che deve gestire tutti i casi delle entità in entrata esistenti nel db o meno, e collegarli all'entità corretta tramite la relazione FK.

Quello che sto vedendo ora è forse che questo non è un albero, più un grafico o un grafico diretto?

Non so se questo extra bit è d'aiuto, ma penso che offra un po 'di più il problema. Tieni presente che non sono davvero alla ricerca di una soluzione reale a questo problema. Ciò che mi infastidisce di più è che questo deve essere un problema che molti sviluppatori incontrano in un modo o nell'altro. Sono curioso di sapere se ci sono dei modi intelligenti per affrontare questo?

    
posta abydal 06.08.2018 - 14:23
fonte

3 risposte

1

C'è una soluzione semplice se non ti dispiace esporre le eccezioni non elaborate.

Immagino tu stia forzando le restrizioni nel Database?

Basta provare a salvare l'oggetto e contrassegnarlo errato se il salvataggio fallisce con qualsiasi messaggio di eccezione lanciato. Ovviamente è meglio importare le cose in "tabelle di importazione" temporanee per consentire un processo di pubblicazione per "Voglio solo importare gli elementi se tutti funzionano"

Normalmente, applicherei la logica di convalida nel repository, che consente messaggi di errore e gestione leggermente più piacevoli. Questo ha incapsulato la logica di validazione, ma in realtà non aiuta con la sua complessità

    
risposta data 06.08.2018 - 17:18
fonte
1

Poiché utilizzi l'API Web, hai considerato qualcosa di simile agli attributi DataAnnotations validator ? Ciò consentirebbe di impostare regole di convalida su proprietà o classi e quindi eventuali errori di convalida verrebbero quindi raccolti come parte di ASP.NET ModelState. Se lo accoppi con un ActionFilter e ResultFilter nella pipeline di richieste che avvia e esegue il commit / rollback di una transazione in entrata e in uscita dall'endpoint" import ", è anche possibile aggiungere la convalida DB in ciascuno di questi attributi.

    
risposta data 06.08.2018 - 17:53
fonte
0

Penso di aver trovato un modo migliore per farlo. Mi ha sempre guardato in faccia. Stavo assumendo erroneamente che tutto debba essere importato come una gigantesca struttura. Ma questo non è necessariamente vero.

Aggiungendo un endpoint di importazione che prende le aziende e le sue entità secondarie (email, phonenumber, dipartimento), l'intero problema è più o meno suddiviso in due parti più piccole e più gestibili.

Il problema che mi ha spinto a scrivere questo post è stato che le aziende dovevano essere importate in modo diverso. Questo cambiamento ha davvero incasinato il flusso che era già abbastanza difficile da capire veramente.

Facendo un endpoint di importazione separato per le aziende, posso mantenere quello precedente per gli utenti, magari ripulirlo un po '. L'endpoint di importazione è attualmente utilizzato solo per gli strumenti che controlliamo, quindi l'api-change non è un problema.

Grazie per le risposte ragazzi.

    
risposta data 07.08.2018 - 06:24
fonte

Leggi altre domande sui tag