Estrazione del repository

3

Supponiamo di avere un oggetto utilizzato dal mio codice, ad esempio Persona:

public class Person {
    public string Name {get;set;}
    public Address Address {get; set;}
}

public class Address {
    public string AddressLine1 {get;set;}
    public string AddressLine2 {get;set;}
    public string City {get;set;}
    public string State {get;set;}
    public string ZipCode {get;set;}
}

Semplice finora. Supponiamo che io mantenga questo oggetto in SQL Server nel modo seguente:

public class PersonEntity {
    public string Name {get;set;}
    public string AddressLine1 {get;set;}
    public string AddressLine2 {get;set;}
    public string City {get;set;}
    public string State {get;set;}
    public string ZipCode {get;set;}
}

Ovviamente, è bene astrarre il modo in cui un oggetto viene mantenuto nel DB dalla logica. In questo modo, posso sostituire l'aspetto dei miei tavoli o la mia tecnologia senza modificare la logica della mia soluzione.

Il problema sorge se voglio usare il repository astratto:

public interface IRepository<TEntity>{
    IEnumerable<TEntity> Get(Func<TEntity, bool> pre);
    ...
}

public class PersonRepository<PersonEntity>{
    ...
}

Ora, se il mio codice di logica aziendale vuole accedere al repository, devono sapere su PersonEntity per poter utilizzare la funzione Get generica. Idealmente, la logica aziendale deve inviare una richiesta come Get(person => person.Address.State == "NY"); invece.

C'è via, elegante e semplice, per raggiungere quel livello di astrazione?

    
posta Husain 14.09.2016 - 17:37
fonte

2 risposte

3

Is there away, elegant and simple, to achieve that level of abstraction?

Non proprio.

Potresti creare un repository per i tuoi oggetti di business, ma probabilmente avrai bisogno di collegare il Queryable lì per chiamare comunque nella versione Entity. Sicuramente qualcosa come Automapper potrebbe essere in grado di farlo ma, perché preoccuparsi? Voglio dire, ad un certo punto qualcosa deve specificare cosa cercare. EF (già, in qualche modo) estrae il tuo data store in modo tale da essere libero di cambiarlo. Ma davvero cambierai significativamente la tua entità di dati lontano dal tuo oggetto business?

Che cosa ti guadagna questa astrazione (leggi: complessità)?

    
risposta data 14.09.2016 - 17:42
fonte
1

Direi che l'oggetto PersonEntity è semplicemente fluff.

Uno dovrebbe essere in grado di ottenere una Persona o un Indirizzo e fare in modo che il livello del repository esegua la mappatura degli oggetti del dominio logico in / da tabelle del database. Tutta questa mappatura / elaborazione avviene nel livello del repository.

Ad esempio, se si passa da SQL a Oracle, mi aspetterei alcune modifiche nel livello di mappatura del repository ma gli oggetti del dominio (Persona / Indirizzo) si portano avanti così come lo sono le interfacce del repository.

Quindi, l'applicazione sarà la stessa con le modifiche localizzate al livello di mappatura del repository. La logica aziendale e la presentazione saranno intoccate. Questa è tutta l'astrazione che dovrebbe essere necessaria.

    
risposta data 14.09.2016 - 18:25
fonte

Leggi altre domande sui tag