Impedisci chiamate DB ripetute a causa dell'approccio orientato agli oggetti nell'app MVC3

Question

Abbiamo un'applicazione MVC3 che abbiamo creato molte piccole azioni e visualizzazioni per gestire l'immissione dei dati ovunque sia necessario. Ad esempio, se si trattava di un blog e volevamo mostrare i commenti, abbiamo un'azione e una vista di commento e possiamo posizionarla ovunque desideriamo, una vista profilo utente e una vista blog post, ecc.

Il problema è questo a causa di ogni piccola vista o azione, è necessario effettuare una chiamata, solitamente allo stesso servizio, più volte per caricamento di una pagina a causa di tutte le altre piccole visualizzazioni che abbiamo nella nostra applicazione. Quindi su una pagina molto grande che contiene queste piccole viste, potremmo avere 80+ chiamate sql con il 40% di esse duplicate e quindi la pagina rallenta. La soluzione attuale consiste nel memorizzare nella cache alcuni dati e passare alcuni dati nel ViewBag, se possiamo, se volete, come il profilo di un utente, controllare se la sua cache o il ViewBag se non lo richiede.

Questo sembra davvero molto sporco per un modello di progettazione e l'approccio viewbag sembra orribile dal momento che deve essere passato dall'alto verso il basso. Abbiamo aggiunto alcuni dati in HttpCurrent.Items per renderlo per una richiesta (invece di memorizzare nella cache dato che i dati possono essere modificati), ma ci deve essere una soluzione pulita che non si senta in errore e sia anche pulita?

EDIT

mi è stato chiesto di essere più specifico e, mentre questa è un'applicazione aziendale interna non posso dare via a gran parte delle specifiche.

Quindi, per mettere questo in un'analogia software. Paragoniamo questo a Facebook. Immagina che questa app MVC abbia un'azione per ogni post di Facebook, quindi sotto quell'azione ha un'altra azione per il pulsante Mi piace e il numero di commenti, quindi un'altra azione per mostrare i migliori commenti all'utente. Il modo in cui è progettata la nostra app otterrebbe il profilo degli utenti corrente in ogni azione (quindi come 4 volte al minimo nella situazione precedente) e quindi l'azione figlio otterrebbe il post parent parent per verificare di avere il permesso di vederlo. Ora puoi prendere in considerazione la memorizzazione nella cache delle chiamate per ogni controllo di sicurezza, bacheca, ecc, ma credo che il caching sia per le cose che saranno necessarie nel corso della vita dell'app, non solo piccoli pezzi qua e là per correggere un errore nel modo in cui il tuo l'applicazione è progettata.

Answer 1

Vedo due potenziali punti in cui il codice potrebbe essere aiutato in base alla mia comprensione del problema.

1. Hai troppe chiamate per pagina. In altre parole, la divisione del lavoro è troppo granulare. Potresti riuscire a combinare le chiamate al tuo servizio creando oggetti che contengono più informazioni. Se si dispone di un oggetto commenti e un oggetto con dati aggregati sui commenti, è possibile combinarli in un oggetto/una chiamata. Solo un pensiero.

2. Caching in modo più efficace. Hai detto che stai già cercando di memorizzare nella cache i dati, ma vuoi un modo migliore per farlo. In un recente progetto su cui ho lavorato ho usato un framework AOP per fare il caching sulle chiamate WCF. Ha funzionato molto bene per lo sviluppo, ma alla fine è stato troppo lento in un sito di produzione di traffico pesante.

Il codice sarebbe venuto fuori in questo modo per una chiamata WCF (approssimativamente):

[Caching(300)] 
Comment GetComment(int commentId); 

si era appena messo un decoratore sulla chiamata WCF con un intervallo di tempo e l'AOP sarebbe preso cura del resto fino al caching. Certo, abbiamo anche utilizzato un framework di caching esterno (AppFabric) per archiviare i risultati delle chiamate WCF.

Aspect Oriented quadro (AOP): http://en.wikipedia.org/wiki/Aspect-oriented_programming Abbiamo usato l'Unità per l'AOP: Enterprise Library Unity vs Other IoC Containers

caldamente in considerazione cercando di memorizzare nella cache il servizio effettivo chiama però, in modo che li si può chiamare ai vostri cuori contenuto.

Answer 2

La cosa migliore da fare è creare un ActionFilter che crei e sminuisca il metodo di persistenza. Ciò garantirà che la parte più costosa dell'accesso ai dati (ovvero la creazione della connessione) sia limitata a una sola volta per richiesta.

public class SqlConnectionActionFilter : ActionFilterAttribute 
    { 
     public override void OnActionExecuting(ActionExecutingContext filterContext) 
     { 
      var sessionController = filterContext.Controller; 

      if (filterContext.IsChildAction) 
       return; 

      //Create your SqlConnection here 
     } 

     public override void OnActionExecuted(ActionExecutedContext filterContext) 
     { 
      if (filterContext.IsChildAction) 
       return; 

      //Commit transaction & Teardown SqlConnection 
     } 
    } 

Answer 3

si è in grado di sostituire uno dei tuoi @ Html.Action() chiama con @ Html.Partial() chiama, passando i dati del modello, invece di basarsi su un metodo di azione per ottenere dal db?

È possibile creare un CompositeViewModel che contenga gli altri ViewModels come proprietà. Ad esempio, potrebbe contenere una proprietà UserViewModel, una proprietà BlogPostViewModel e una proprietà Collection<BlogComment>.

Nel metodo di azione che restituisce la vista contenitore/master, è possibile ottimizzare l'accesso ai dati. Sembra che tu abbia già un sacco di codice ripetibile estratto da un servizio, ma non hai inserito alcun codice, quindi non sono sicuro di quanto possa essere ASCIUTTO questo approccio.

Ma se si può fare questo senza ripetere un sacco di codice da vostre azioni bambino, è possibile utilizzare @Html.Partial("~/Path/to/view.cshtml", Model.UserViewModel) nella vista maestro, e mantenere il metodo di azione bambino per altre pagine che non hanno una così pesante caricare.

Answer 4

Il problema è: se stai facendo la query 80 volte, allora stai colpendo il db 80 volte. Mettere una cache con scope richiesta è la soluzione migliore. Il modo più elegante di implementarlo è tramite AOP, quindi il tuo codice non si preoccupa di quel problema.