Quanto lontano posso allontanarmi dal mio modello di dominio originale e avere ancora i benefici di un ORM?

Question

Quanto lontano posso allontanarmi dal mio modello di dominio originale e avere ancora i benefici di un ORM?

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

3

Ho i seguenti domini :

public class User
{
    public int Id { get; set; }
    public ICollection<Product> Products { get; set; }
}

public class Product
{
    public int Id { get; set; }
    public decimal Price { get; set; }
}

La mia entità utente ha una collezione di prodotti e nessun prodotto può essere creato senza un utente. Sto usando l'approccio Code First di EntityFramework, che richiede di dichiarare la chiave esterna sull'entità Product, cambiandola in:

public class Product
{
    public int Id { get; set; }
    public decimal Price { get; set; }
    public int UserId { get; set; }
}

Non mi piace molto perché, dal punto di vista del dominio , non è interessante avere la chiave esterna dell'utente mostrata nell'entità Prodotto. Questo, comunque, non mi danneggia e posso conviverci. Ti prego, ricordati che sto usando un ORM per semplificare il mio lavoro, quindi mi va bene in parte.

Va bene alle mie entità di dominio che possiedono proprietà o cose simili solo per soddisfare i miei requisiti di scelta ORM?

domain-driven-design entity-framework orm

posta TonySniper 30.07.2014 - 03:36

fonte

2 risposte

Leggi altre domande sui tag domain-driven-design entity-framework orm

Qual è una buona strategia per sviluppare app eseguite in console e come API? Finestre multiple

score 3 · Answer 1

Ho sentito Vaugn Vernon dire di EF che non dovresti perdere tempo a combattere contro EF per farlo sembrare un modello di dominio perché EF è molto più inflessibile di altri ORM. Quindi il suo consiglio se vuoi usare EF è semplicemente avere un oggetto di stato dietro le quinte che si adatti a EF e poi lasciare che il tuo modello di dominio lo usi per l'archiviazione dei dati.

score 2 · Answer 2

Se si utilizza l'API di mappatura fluente facendo:

HasMany(x => x.Products);

Dovrebbe essere sufficiente per creare la relazione di chiave esterna tra utente e prodotto senza la proprietà UserId da specificare sul prodotto.

Si noti inoltre che EF può mappare i dati a proprietà private (e utilizzare ctors e setter privati) quindi se un dettaglio del genere fosse assolutamente inevitabile dovresti essere in grado di evitare di esporlo nel tuo dominio.

Come nota a margine (potrebbe essere solo il tuo codice di esempio); se vuoi caricare pigro Prodotti, devi specificarlo come virtuale o specificarlo come inclusione quando esegui le tue query.