Qual è il modo migliore: crea il proprio wrapper per DbContext o usa DbContext in Controller

La risposta alla tua domanda è principalmente basata sull'opinione. Nessuno può dire definitivamente "un modo è meglio dell'altro" fino a quando molte altre domande avranno una risposta. Qual è la dimensione / ambito / budget del tuo progetto? Quanti sviluppatori ci lavoreranno? Avrà solo controller MVC (basati sulla vista) o avrà anche controller API (basati sui dati)? In quest'ultimo caso, quanta sovrapposizione ci sarà tra i metodi di azione MVC e API, se presenti? Avrà client non web, come WPF? Come pensi di testare l'applicazione?

Entity Framework è uno strumento DAL (Data Access Layer). I controller sono strumenti di gestione delle richieste e delle risposte client HTTP. A meno che la tua applicazione non sia pura CRUD (il che è dubbio), probabilmente ci sarà un qualche tipo di elaborazione della business logic che dovrai fare tra quando ricevi una richiesta web su HTTP e quando salvi i dati di quella richiesta su un database usando EF ( il campo X è obbligatorio, se si forniscono dati per il campo Y, è necessario fornire anche i dati per il campo Z, ecc.). Quindi, se si utilizza il codice EF direttamente nei controller, ciò significa che la logica di elaborazione aziendale sarà quasi sicuramente presente nei controller insieme a esso.

Quelli di noi che hanno una discreta esperienza nello sviluppo di applicazioni non banali con .NET tendono a sviluppare opinioni secondo cui né i controller né la logica di accesso ai dati aziendali dovrebbero essere presenti nei controller a causa di alcune difficoltà che emergono quando viene implementato tale progetto. Ad esempio, quando si inserisce la logica di richiesta e risposta web / http, insieme alla logica di business e alla logica di accesso ai dati in un controller, si finisce per testare tutti quegli aspetti dell'applicazione dalle azioni del controller stesso (che è una violazione evidente del Single Principio di responsabilità, se ti interessa il design SOLID). Supponiamo inoltre che sviluppi un'applicazione MVC tradizionale con controller che restituiscono visualizzazioni, quindi decidi di voler estendere l'app ad altri client come iOS / Android / WPF / o altri client che non comprendono le visualizzazioni MVC. Se decidi di implementare una serie secondaria di azioni del controller basate sui dati WebAPI, duplicherai la logica di accesso ai dati e agli affari in almeno 2 posizioni.

Tuttavia, ciò non prende la decisione di mantenere intrinsecamente "peggio" tutte le logiche di accesso a dati e business nei controller rispetto a un design alternativo. Qualsiasi decisione presa durante la progettazione dell'architettura di un'applicazione Web avrà vantaggi e svantaggi. Ci saranno sempre compromessi, indipendentemente dalla rotta scelta. I vantaggi di mantenere tutto il codice dell'applicazione nei controller possono includere costi inferiori, complessità e quindi time-to-market. Non ha senso progettare eccessivamente architetture complesse per applicazioni molto semplici. Per quanto sfortunato, personalmente non ho mai avuto il piacere di sviluppare una semplice applicazione, quindi sono nell'opinione generale che mantenere il codice di accesso ai dati e agli affari nei controller non sia "probabilmente" una buona decisione di progettazione a lungo termine.

Se sei veramente interessato alle alternative, ti consiglio di leggere questi due articoli . Sono un buon primer su come si potrebbe implementare un modello command & query (CQRS) che i controller possono utilizzare. EF implementa immediatamente sia il repository che i modelli di unità di lavoro, ma ciò non significa necessariamente che sia necessario "racchiuderlo" per spostare il codice di accesso ai dati all'esterno dei controller. Buona fortuna a prendere questo tipo di decisioni per il tuo progetto.

public async Task<ActionResult> Index() {
    var user = await query.Execute(new UserById(1));
    return View(user);
}