Esempi di raccolta classi di pattern repository con caricamento Lazy / Eager

Question

Esempi di raccolta classi di pattern repository con caricamento Lazy / Eager

#1 da (1 voti)

1

Quando si implementa il repository è abbastanza facile per una classe autonoma. Purtroppo, non siamo in grado di utilizzare un ORM per gestire l'accesso ai dati, quindi sto tentando di ricreare manualmente alcune funzionalità (uggh).

Ad esempio, se ho un utente di classe, implementa un IRepository generico. Inoltre, potrei avere una classe chiamata Task che implementa anche IRepository. Se esiste una relazione uno-a-molti da utente a compito, vorrei avere un codice come questo:

Public class User : IRepository<T> where T : IEntity
{
    public string Name{get;set;}

    public list<Task> ....(This is where I start getting fuzzy)
}

Mi piacerebbe essere in grado di concatenare le mie chiamate, ad esempio:

User.Tasks;

Restituisce un elenco di tutte le attività dell'utente. Come dovrebbe essere l'accesso ai dati per l'attività per gestire questo, Inoltre, come dovrebbe essere definito il compito nella classe User. E infine, che ne dici di desideroso / pigro che carica l'attività su un utente? Come può essere realizzato?

collections design-patterns repository class-design

posta TreK 15.01.2016 - 01:31

fonte

1 risposta

Leggi altre domande sui tag collections design-patterns repository class-design

Definizione esatta di Sec-Websocket-Key nel protocollo Websocket Modello di account utente con due o tre profili possibili

score 1 · Answer 1

Non implementare un'interfaccia di repository sull'entità stessa, crea una classe di servizio separata per essa.

Dato il tuo esempio, non considererei affatto un elenco di attività per l'utente basta creare un TaskRepository con una query ListTasksByUser.

Se non hai bisogno di accedere direttamente alle attività (indipendentemente dall'utente), potresti considerare di archiviare le attività insieme agli altri dati utente. Un database di documenti funzionerebbe bene lì. Con un DB relazionale puoi nascondere il join all'interno del repository.

Se hai intenzione di avere sia un UserRepository che un TaskRepository considererei solo l'associazione per ID e lasciarlo lì.

Per allegare riferimenti all'oggetto reale, con impazienza o pigramente, potresti trovare un mucchio di soluzioni, una può richiedere più strumentazione sulla tua entità che su altre.

Puoi mappare le tue entità a DTO che contengono chiavi esterne ID, quando caricate caricheranno avidamente l'entità estranea e la assegneranno. Una volta eseguito pigramente, è possibile utilizzare un proxy attorno alla proprietà dell'entità e caricare l'accesso alla proprietà proxy.

Un'altra opzione potrebbe essere quella di creare un piccolo oggetto di riferimento da utilizzare per ogni relazione contenente un Lazy<T> e l'ID. Dovresti fornire i delegati per i valori Lazy dopo aver caricato i dati.

IMHO è più problemi quindi ne vale la pena, il carico pigro è sopravvalutato. O vuoi qualcosa con entusiasmo o per niente. Un percorso di codice che tocca molte proprietà lazy può dare un sacco di problemi di prestazioni (selezionare + 1).