Modello DTO + Caricamento pigro + Entity Framework + ASP.Net MVC + Auto Mapper

Question

In primo luogo, scusa per una lunga domanda, ma devo fornire alcune informazioni di base.

Stiamo creando un'applicazione che utilizza ASP.net MVC, Modelli JQuery, Entity Framework, WCF e abbiamo utilizzato POCO come livello del dominio. Nella nostra applicazione, c'è un livello di servizi WCF per lo scambio di dati con l'applicazione ASPC MVC e utilizza gli oggetti di trasferimento dati (DTO) da WCF a MVC.

Inoltre, l'applicazione utilizza il caricamento lento in Entity Framework utilizzando AutoMapper durante la conversione di domini in DTO nel nostro livello di servizio WCF.

nostro backend Architettura come segue (WCF Services -> I gestori -> Repository -> Entity Framework (POCO))

Nella nostra applicazione, non usiamo Visualizza i modelli come noi non vogliamo un altro livello di mappatura per l'applicazione MVC e utilizziamo solo DTO come modelli di vista.

Generalmente, disponiamo di DTO normali e Lite per domini come Customer, CustomerLite, ecc. (L'oggetto Lite ha poche proprietà rispetto a Normal).

Ora abbiamo delle difficoltà con gli DTO perché la nostra struttura DTO sta diventando più complessa e quando pensiamo alla manutenibilità (con struttura gerarchica generale di DTO) perdiamo prestazioni.

Per esempio,

Abbiamo Clienti Visualizza pagina e la nostra gerarchia DTO come segue

public class CustomerViewDetailsDTO 
{ 
    public CustomerLiteDto Customer{get;set;} 
    public OrderLiteDto Order{get;set;} 
    public AddressLiteDto Address{get;set;} 
} 

In questo caso non vogliamo alcuni campi di OrderLiteDto per questo punto di vista. Ma qualche altra visione ha bisogno di quei campi, così per facilitare che usiamo quella struttura.

Quando si tratta di Auto Mapping, mappiamo CustomerViewDetailsDTO e otterremo dati aggiuntivi (che non è richiesto per una vista particolare) da Lazy Loading (Entity Framework).

Le mie domande:

1. Esiste un meccanismo che possiamo utilizzare per migliorare le prestazioni, mentre considerando la manutenibilità?

2. È possibile utilizzare Automapper con più funzioni di mapping basate sulla visualizzazione della mappa per lo stesso DTO?

Answer 1

Prima di non usare caricamento pigro come probabilmente si tradurrà in Selezionare N + 1 problemi o simili.

Selezionare N + 1 è un anti-pattern di accesso ai dati in cui il database è accessibile in modo subottimale.

In altre parole, l'utilizzo del caricamento lazy senza le raccolte di caricamento avide fa sì che Entity Framework entri nel database e restituisca i risultati una riga alla volta.

Usa jsRender per i modelli in quanto è molto più veloce di modelli JQuery: Render Bemchmark ed ecco un bel informazioni per come usarlo: Reducing JavaScript Code Using jsRender Templates in HTML5 Applications

In generale, abbiamo Normale e Lite DTOs per il dominio, come clienti , CustomerLite, ecc. (L'oggetto Lite ha poche proprietà rispetto al normale).

vostro normale DTO è probabilmente una ViewModel come ViewModels possono o non possono mappare 00:59 alle DTOS, e ViewModels spesso contengono logica spinto indietro dal punto di vista, o dare una mano con spingendo dati al modello su un utente di risposta. I DTO non hanno alcun comportamento e il loro scopo è ridurre il numero di chiamate tra i livelli dell'applicazione.

C'è qualche meccanismo che è possibile utilizzare per migliorare le prestazioni considerando la manutenibilità?

Usa un ViewModel per una vista e non dovrai preoccuparti della manutenibilità. Personalmente di solito creo una classe abtract che è una base, e per modificare, creare o elencare eredisco quella classe e aggiungo proprietà specifiche per una vista. Quindi per un esempio, la vista Crea non ha bisogno di PropertyId (dato che qualcuno può dirottare il tuo post e postarlo), quindi solo Edit e List ViewModels hanno una proprietà PropertyId esposta.

È possibile utilizzare Automapper con più funzioni di mapping basate sulla visualizzazione della mappa per lo stesso DTO?

È possibile utilizzare automapper per definire ogni mappa, ma la domanda è, quanto sia complicata la mappa sarà. Usando un ViewModel per view e le tue mappe saranno semplici da scrivere e mantenere. Devo sottolineare che non è consigliabile utilizzare Automapper nel codice di accesso ai dati come:

Un difetto di Automapper è quella proiezione dal dominio oggetti costringe comunque l'intero oggetto dominio da interrogare e caricato.

Fonte: Autoprojecting LINQ queries

È possibile utilizzare un set di estensione che sono limitati fin d'ora per accelerare il mapping in codice di accesso ai dati: Stop using AutoMapper in your Data Access Code

saluti