separazione degli interessi Pattern Repository & Entity Framework 3.5

Question

Sto cercando di essere uno sviluppatore migliore ...

quello che sto lavorando con:

1. .Net MVC Framework 1.0
2. Entity Framework 3,5

ho fatto qualche lettura e penso che quello che voglio fare è:

1. Creare un repository per ciascun aggregato nel dominio. Un repository di ordini, ad esempio, gestirà gli OrderItem di un ordine.
2. Creare un livello di servizio per gestire la business logic. Ogni repository avrà un oggetto di servizio corrispondente con metodi simili.
3. Creare DTO tra il repository e il servizio
4. Possibilmente creare ViewModels che sono classi da utilizzare per la visualizzazione.

Ho un repository un'interfaccia base che le mie interfacce repository aggregati attueranno ...

public interface IRepository<T> 
    { 
     IEnumerable<T> ListAll(); 
     T GetById(int id); 
     bool Add(T entity); 
     bool Remove(T entity); 
    } 

mio Ordine interfaccia Repository è definito come segue ... ci saranno probabilmente altri metodi, come ho più in questo esercizio di apprendimento.

public interface IOrderRepository : IRepository<Order> 
{ 
} 

Le mie classi di servizio sono essenzialmente definite come i repository, tranne per il fatto che ogni implementazione di servizio include la logica di business. I servizi avranno un'interfaccia repository nel costruttore (non sono pronto per IoC in questo esercizio, ma credo che sia dove vorrei finire in fondo alla strada).

1. Le implementazioni del repository eseguiranno il push e il pull dal database utilizzando Entity Framework. Quando si recuperano dati; i metodi restituiranno solo i DTO e non gli oggetti EF generati
2. I servizi (come li chiamo loro) controlleranno il repository ed eseguiranno la logica di business. I servizi sono ciò che vedrai nel controller, ad esempio _orderService.GetById (1).
3. Questo è il punto in cui ho iniziato a capovolgere e potrei usare qualche feedback ... dovrei forse avere le mie classi di servizio per popolare classi ViewModel ... non dovrei avere classi ViewModel .... forse è troppa mappatura da un tipo ad un altro?

Mi piacerebbe avere un riscontro sulla direzione che sto seguendo per quanto riguarda la separazione delle preoccupazioni.

Grazie

Answer 1

penso che ci si sta muovendo nella giusta direzione sul modello Repository. Per quanto riguarda la tua domanda sulle classi ViewModel, ti suggerisco di utilizzare qualcosa che trasformi l'output degli output del metodo di servizio aziendale in alcuni output desiderati. Ad esempio, il servizio aziendale dell'Ordine potrebbe avere un metodo chiamato GetOrders(). Utilizzando un attributo personalizzato è possibile definire il tipo di classe di visualizzazione per esso. La vista è in grado di ottenere l'output di questo metodo, se possibile si unisce ad altri tipi di dati e restituisce il risultato come una raccolta di oggetti con tipi anonimi.In questo caso la vista assumerà IQueryable<Order> o IEnumerable<Order> come input e restituirà IList come output.

Questo metodo è di grande aiuto quando è necessario mostrare diversi tipi di viste dei dati sul lato client. Abbiamo già utilizzato qualcosa di simile (ma più complesso) a questo metodo nella struttura della nostra azienda.