Quali vantaggi posso ottenere aggiornando la struttura ASP.NET (Webform) + DAL (EF) + Repository + BLL in MVC?

Question

Quali vantaggi posso ottenere aggiornando la struttura ASP.NET (Webform) + DAL (EF) + Repository + BLL in MVC?

#1 da (2 voti)

2

Sto definendo un approccio che meglio si adatta alle nostre esigenze di sviluppo di una grande applicazione web. Per ora, sto pensando di andare con un'architettura ASP.NET con un DAL utilizzando Entity Framework, un concetto di repository per non accedere a DAL direttamente da BLL e una BLL che chiama il repository e rendere ogni manipolazione necessaria per preparare i dati per inserire un livello di presentazione (file .aspx).

Non ho intenzione di utilizzare i controlli ASP.Net e preferisco mantenere le cose semplici e leggere usando semplici controlli html, jQuery UI ed effettuare la maggior parte delle chiamate server con jQuery Ajax. A volte, quando necessario, ho intenzione di utilizzare i gestori (.ashx) per chiamare i metodi BLL che restituiranno JSON o HTML al client per le cose dinamiche.

La mia soluzione ha anche un progetto di test che Mock the Repository con i dati in-memory non si riposa sul database per testare i metodi BLL ...

Potrebbe essere utile aggiungere che costruiremo una grande applicazione su questa architettura con centinaia di tabelle e procedure di memorizzazione con molta lettura e scrittura nel database.

La mia domanda è, avendo questa architettura in mente, c'è qualche evidente vantaggio che posso ottenere usando un progetto MVC3 invece della base di architettura descritta su Webform? Vedi qualche problema in questa architettura che potrebbe causarci problemi durante i prossimi passi di sviluppo?

Conosco il pattern MVC per utilizzarlo in altri progetti con Django ... ma l'implementazione di Microsoft MVC è molto più complessa e dettagliata di Django MVC ed è per questo che esita (o aspetto una piccola spinta?) proprio ora prima di buttarci dentro ... Siamo in un vero progetto con scadenze e non vogliamo rallentare il processo di sviluppo senza reali benefici.

asp.net-mvc

posta Etienne 18.09.2012 - 20:19

fonte

1 risposta

Leggi altre domande sui tag asp.net-mvc

Qual è la differenza tra Times e Dup in Assembly Language? Sviluppo di un'interfaccia in un sistema dinamico

score 2 · Accepted Answer

Secondo me, andrei con MVC. Ci sono molte ragioni "belle da avere". Viste basate sul modello, autenticazione basata sugli attributi, controllo del routing, ecc. MVC ti consentirà di separare in modo più pulito l'interfaccia utente anche dallo strato di codice. La mia più grande lamentela nei moduli Web ASP.net è il ciclo di vita degli eventi della pagina, specialmente se utilizzato con pagine e controlli principali. È un vero dolore ricevere tutto per renderlo correttamente. Ultimamente, nei miei progetti MVC visualizzerò una vista, che è legata a un modello, e quindi gli aggiornamenti successivi utilizzano jQuery per effettuare chiamate ajax e aggiornare solo la pagina dove è necessario.

Ho avuto solo esperienza con asp.net MVC, nessun altro framework MVC, ma in realtà è molto più facile da gestire di quanto possa sembrare, purché si disponga di una sorta di "View Models" che comprende i dati necessari per una vista, scaricarlo sulla pagina è molto semplice: una volta adottata la "semplicità" di MVC, nessun valore di impostazione basato sulle proprietà nel codebehind, i cicli foreach sulla vista e le viste parziali legate al modello semplice, in realtà è un bella esperienza.

C'è una certa curva di apprendimento per allontanarsi dalle tendenze di asp.net e ti costringerà ad aggiungere "livelli" all'app per mantenere le cose organizzate, ma penso che sia la strada da percorrere. Puoi sicuramente applicare gli stessi concetti a WebForms, ma ancora una volta, l'argomento che definisco per me è la pagina eventi, non mi mancano affatto ..

L'unica lentezza verrà con l'apprendimento di ciò che funziona per voi ragazzi. Una volta ottenuto un controllo, sarà uno sviluppo rapido e pulito, e se si va nella giusta direzione, si potrebbe finire con un livello di servizio ben definito. (Ovviamente si può dire lo stesso con le webform, ma si ottiene il controllo completo del client con MVC (nessun nome di controllo di visualizzazione o stravagante)). Consiglio vivamente di allontanarmi da webForms.