ASP.NET MVC è lento rispetto all'approccio tradizionale?

Questa è una domanda molto soggettiva per alcuni aspetti, ma cercherò di rispondere alle parti che possono essere ragionevolmente risolte.

Le prestazioni di MVC non sono un po 'lente?

No. Naturalmente, è possibile implementare il pattern in modo veramente scadente per farlo funzionare male (ma questo è vero per tutto e per tutto), ma il pattern stesso non è intrinsecamente lento in alcun modo. La mappatura degli URL ai metodi delle classi controller è assolutamente banale e non c'è ragione per non avere prestazioni eccellenti.

Sì, ci sarà una piccola quantità di overhead, ma ci sono diversi tipi di overhead con le tradizionali applicazioni ASP.NET o PHP. Non pre-ottimizzare . Invece, scegli il framework / strumenti che rendono tu più performante.

Anche la curva di apprendimento è molto ripida?

La tua curva di apprendimento è diversa da quella di tutti, ma nella mia esperienza personale, era piuttosto l'opposto. Con Ruby on Rails e ASP.NET MVC, ho scoperto che il pattern MVC corrispondeva in modo così ovvio e intuitivo alla natura delle applicazioni Web che la curva di apprendimento era praticamente inesistente. Piuttosto, sono rimasto deluso da me stesso per non essere stato colui che ne ha fatto comunque.

ASP.NET MVC è ciò che chiami "App Layer".

Quindi dovresti comunque creare 3 cartelle Livello applicazione, Livello aziendale e Livello dati di cui gli ultimi due contengono esattamente ciò che conterrebbero in altri tuoi progetti.

La cartella del livello App conterrà quindi l'intero progetto ASP.NET MVC con tutte le sue sottocartelle (modelli, controller, contenuto, script, ...).

Per quanto riguarda le prestazioni, non penso che importi davvero. Non useresti mai "Routing" per invocare un livello Business o il metodo del livello dati. Si utilizza solo "Routing" per invocare i metodi del controller, quindi per l'interfaccia utente (il livello App nella terminologia). Dovresti quindi richiamare i tuoi metodi Business Layer dai tuoi controllori, in modo che accadano con le stesse prestazioni come altri tuoi progetti.

La stratificazione e l'organizzazione hanno sempre dei costi. Se hai davvero bisogno di prestazioni, dovresti controllare dove e se vale la pena e, in caso affermativo:

• inizia a rimuovere i livelli
• quando non ci sono più livelli, inizia a rimuovere i metodi
• se non ci sono metodi, pensa a c

Nel peggiore dei casi, ti ritroverai con un codice sempre più performante che puoi capire solo con la portabilità o la flessibilità 0.