Entity Framework - È una cattiva pratica lavorare con gli ID a livello di business logic?

Question

Entity Framework - È una cattiva pratica lavorare con gli ID a livello di business logic?

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

1

Recentemente mi sono imbattuto in un'applicazione EF6 in cui la logica è guidata pesantemente dall'uso di ID, cosa che non avevo mai visto prima.

Una volta che un'entità viene caricata da EF nel DAL, viene mappata su un altro oggetto POCO quasi identico che si trova nel livello di business logic.

Ogni volta che le entità vengono elaborate nella Business Logic, le relazioni vengono determinate utilizzando gli ID, ad esempio:

var applesOnTree = forestApples.Where(a => a.TreeID == tree.ID)

Questo mi è sembrato estremamente strano, mentre prima avevo sempre lavorato con applicazioni che esprimevano relazioni usando oggetti:

var applesOnTree = tree.Apples;

È normale utilizzare ID generati nella business logic come quando si utilizza EF?

Mi sembra strano personalmente. È meglio non lavorare mai con gli ID tranne nel livello DAL? O questa capacità è considerata un utile vantaggio di EF?

Suppongo che sia utile in quanto ti consente di tenere traccia di ciò che non è stato / non è stato ancora persistuto nel DB?

c# entity-framework

posta FBryant87 27.07.2017 - 14:53

fonte

2 risposte

Leggi altre domande sui tag c# entity-framework

sconti dinamici per prodotti specifici È sempre carico di dati da un database un difetto di progettazione?

score 1 · Answer 1

Questo mi sembra una pratica normale. L'unica cosa che non è chiara è il motivo per cui la si rapporta a EF?

Il problema con Tree.Apples è il seguente:

È inefficiente recuperare le mele albero per albero piuttosto che GetTreesInForest (3), GetApplesInForest (3) e quindi mapparle.
Si trova che ogni Apple ha semi che devono anche essere popolati. Ora non puoi ottenere un singolo albero senza riportare una tonnellata di dati. Sei costretto ad avere TreeLites o il caricamento lazy, tutto ciò è più complicato del semplice non avere oggetti figli.

score 0 · Answer 2

Modelli relazionali e modelli di oggetti non sono gli stessi.

Non devi modellare con gli oggetti perché i tuoi dati sono in memoria. Non è necessario utilizzare un modello relazionale perché i dati si trovano in un database.

Tuttavia, tradizionalmente, è così che è stato fatto. Perché è stato fatto in quel modo ha più a che fare con gli strumenti quindi con il design. Cercando di lavorare con entrambi i modelli crea Object-relational_impedance_mismatch .

E naturalmente ci sono strumenti per risolvere questi problemi strumento creato: Object-relational_mapping

Questo non vuol dire che dovresti lavorare solo con un modello. Ma quando lavori con due stai creando un vero lavoro. Delega il lavoro su uno strumento e non sorprenderti se ti delude. Conosco negozi con gruppi di persone dediti a riprendere questo lavoro dallo strumento.