Sito Web ASP.NET o applicazione Web ASP.NET?


Answers

Il sito Web è ciò che viene distribuito su un server Web ASP.NET come IIS. Solo un mucchio di file e cartelle. Non c'è nulla in un sito Web che ti lega a Visual Studio (non esiste un file di progetto). La generazione del codice e la compilazione di pagine Web (come .aspx, .ascx, .master) vengono eseguite dinamicamente in fase di runtime e le modifiche a questi file vengono rilevate dal framework e ricompilate automaticamente. È possibile inserire il codice che si desidera condividere tra le pagine nella speciale cartella App_Code, oppure è possibile precompilarlo e inserire l'assieme nella cartella Bin.

L'applicazione Web è un progetto speciale di Visual Studio. La principale differenza con i siti Web è che quando si genera il progetto tutti i file di codice vengono compilati in un unico assembly, che viene inserito nella directory bin. Non si distribuiscono i file di codice sul server Web. Invece di avere una cartella speciale per i file di codice condivisi, puoi metterli ovunque, proprio come faresti nella libreria di classi. Poiché le applicazioni Web contengono file che non si intende distribuire, come file di progetto e di codice, esiste un comando Pubblica in Visual Studio per l'output di un sito Web in una posizione specificata.

App_Code vs Bin

La distribuzione di file di codice condivisi è generalmente una cattiva idea, ma ciò non significa che devi scegliere l'applicazione Web. È possibile avere un sito Web che fa riferimento a un progetto di libreria di classi che contiene tutto il codice per il sito Web. Le applicazioni Web sono solo un modo conveniente per farlo.

CodeBehind

Questo argomento è specifico per i file .aspx e .ascx. Questo argomento è di rilevanza decrescente in nuove strutture applicative come ASP.NET MVC e pagine Web ASP.NET che non utilizzano i file codebehind.

Avendo tutti i file di codice compilati in un unico assembly, inclusi i file codebehind di pagine .aspx e controlli .ascx, in Web Applications è necessario ricostruire ogni piccola modifica e non è possibile apportare modifiche in tempo reale. Questo può essere un vero problema durante lo sviluppo, dal momento che è necessario continuare a ricostruire per vedere le modifiche, mentre con le modifiche dei siti Web vengono rilevate dal runtime e le pagine / i controlli vengono ricompilati automaticamente.

Avere il runtime di gestire gli assembly codebehind è meno utile per te, dal momento che non devi preoccuparti di dare pagine / controlli a nomi univoci, o di organizzarli in namespace diversi.

Non sto dicendo che la distribuzione di file di codice sia sempre una buona idea (specialmente nel caso di file di codice condivisi), ma i file di codice devono contenere solo codice che esegue attività specifiche dell'interfaccia utente, gestori di eventi wire-up, ecc. stratificato in modo che il codice importante finisca sempre nella cartella Bin. In tal caso, la distribuzione di file codebehind non dovrebbe essere considerata dannosa.

Un'altra limitazione delle applicazioni Web è che è possibile utilizzare solo la lingua del progetto. Nei siti Web è possibile avere alcune pagine in C #, alcune in VB, ecc. Non è necessario il supporto speciale di Visual Studio. Questa è la bellezza dell'estensibilità del provider di build.

Inoltre, nelle applicazioni Web non si ottiene il rilevamento degli errori nelle pagine / controlli poiché il compilatore compila solo le classi codebehind e non il codice di markup (in MVC è possibile risolvere ciò utilizzando l'opzione MvcBuildViews), che viene compilato in fase di runtime.

Visual Studio

Poiché le applicazioni Web sono progetti di Visual Studio, alcune funzionalità non sono disponibili nei siti Web. Ad esempio, è possibile utilizzare gli eventi di compilazione per eseguire una serie di attività, ad es. Minify e / o combinare file Javascript.

Un'altra interessante funzionalità introdotta in Visual Studio 2010 è la trasformazione Web.config . Anche questo non è disponibile nei siti Web. Ora funziona con i siti Web in VS 2013.

La creazione di un'applicazione Web è più veloce della creazione di un sito Web, specialmente per siti di grandi dimensioni. Ciò è principalmente dovuto al fatto che le applicazioni Web non compilano il codice di markup. In MVC se si imposta MvcBuildViews su true, questo compila il codice di markup e si ottiene il rilevamento degli errori, che è molto utile. Il lato negativo è che ogni volta che si crea la soluzione si costruisce il sito completo, che può essere lento e inefficiente, specialmente se non si sta modificando il sito. Mi trovo a girare MvcBuildViews on e off (che richiede uno scaricamento del progetto). D'altra parte, con i siti Web è possibile scegliere se si desidera creare il sito come parte della soluzione oppure no. Se si sceglie di non farlo, la creazione della soluzione è molto rapida e si può sempre fare clic sul nodo Sito Web e selezionare Genera, se sono state apportate modifiche.

In un progetto di applicazione Web MVC sono disponibili comandi e finestre di dialogo aggiuntivi per attività comuni, come "Aggiungi vista", "Vai alla vista", "Aggiungi controller", ecc. Questi non sono disponibili in un sito Web MVC.

Se si utilizza IIS Express come server di sviluppo, nei siti Web è possibile aggiungere directory virtuali. Questa opzione non è disponibile nelle applicazioni Web.

NuGet Package Restore non funziona sui siti Web, devi installare manualmente i pacchetti elencati su packages.config Package Restore ora funziona con i siti Web che iniziano con NuGet 2.7

Question

Quando avvio un nuovo progetto ASP.NET in Visual Studio, è possibile creare un'applicazione Web ASP.NET o creare un sito Web ASP.NET.

Qual è la differenza tra l'applicazione Web ASP.NET e il sito Web ASP.NET? Perché dovrei sceglierne uno rispetto all'altro?

La risposta è diversa in base alla versione di Visual Studio che sto utilizzando?




Modello di progetto di applicazione Web

  • Fornisce la stessa semantica del progetto Web come progetti Web di Visual Studio .NET. Ha un file di progetto (struttura basata su file di progetto). Modello di costruzione: tutto il codice nel progetto viene compilato in un unico assieme. Supporta IIS e il server di sviluppo ASP.NET integrato. Supporta tutte le funzionalità di Visual Studio 2005 (refactoring, generics, ecc.) E di ASP.NET (pagine master, membership e login, navigazione del sito, temi, ecc.). L'utilizzo delle estensioni del server di FrontPage (FPSE) non è più un requisito.

Modello di progetto del sito Web

  • Nessun file di progetto (basato sul file system).
  • Nuovo modello di compilazione.
  • Compilazione dinamica e lavoro su pagine senza creare l'intero sito su ogni visualizzazione di pagina.
  • Supporta IIS e il server di sviluppo ASP.NET integrato.
  • Ogni pagina ha il proprio assembly.
  • Modello di codice Defferent.



Siti Web: non verrà creato alcun file di soluzione. Se vogliamo creare siti web non è necessario lo studio visivo.

Applicazione Web: verrà creato un file di soluzione. Se vogliamo creare un'applicazione web dovrebbe essere necessario lo studio visivo. Creerà un singolo file .dll nella cartella bin.




A meno che tu non abbia una necessità specifica per un progetto compilato dinamicamente, non utilizzare un progetto di sito web .

Perché? Perché il progetto del sito web ti guiderà sul muro quando cerchi di cambiare o capire il tuo progetto. Le funzionalità di ricerca della digitazione statica (ad esempio trova utilizzi, refactoring) in Visual Studio occuperanno per sempre qualsiasi progetto di dimensioni ragionevoli. Per ulteriori informazioni, vedere la domanda Overflow dello stack Lenta "Trova tutti i riferimenti" in Visual Studio .

Non riesco davvero a capire perché abbiano abbandonato le applicazioni Web in Visual Studio 2005 per il tipo di progetto del sito Web di carboncaruncolo, che induce al dolore, drenaggio e produttività.




Questo potrebbe sembrare un po 'ovvio, ma penso che sia qualcosa che viene frainteso perché Visual Studio 2005 è stato spedito solo originariamente con il sito web. Se il tuo progetto riguarda un sito web che è abbastanza limitato e non ha molta separazione logica o fisica, il sito web va bene. Tuttavia, se è veramente un'applicazione web con moduli diversi in cui molti utenti aggiungono e aggiornano i dati, si sta meglio con l'applicazione web.

Il più grande pro del modello di sito web è che qualsiasi cosa nella sezione app_code sia compilata dinamicamente. È possibile effettuare aggiornamenti di file C # senza una ridistribuzione completa. Tuttavia questo arriva ad un grande sacrificio. Un sacco di cose accadono sotto le coperte che sono difficili da controllare. Gli spazi dei nomi sono difficili da controllare e l'utilizzo specifico della DLL esce di default dalla finestra per qualsiasi cosa sotto app_code poiché tutto è compilato dinamicamente.

Il modello di applicazione web non ha una compilazione dinamica, ma ottieni il controllo sulle cose che ho menzionato.

Se si sta effettuando uno sviluppo a più livelli, consiglio vivamente il modello di applicazione Web. Se stai facendo un sito web limitato o un'implementazione rapida e sporca, il modello del sito web potrebbe avere dei vantaggi.

Un'analisi più dettagliata può essere trovata in:




Le applicazioni Web richiedono più memoria, presumibilmente perché non hai altra scelta che compilare un singolo assembly. Ho appena convertito un sito legacy di grandi dimensioni in un'applicazione web e ho problemi con l'esaurimento della memoria, sia in fase di compilazione con

Unexpected error writing metadata to file '' -- 
Not enough storage is available to complete this operation. 

errore e in fase di esecuzione con questo errore:

Exception information: 
    Exception type: HttpException 
    Exception message: Exception of type 'System.OutOfMemoryException' was thrown.
   at System.Web.Compilation.BuildManager.ReportTopLevelCompilationException()

Il mio consiglio per la conversione di siti più grandi su hardware legacy con vincoli di memoria è quello di consentire a te stesso la possibilità di tornare al modello del sito web. Anche dopo un iniziale successo, i problemi potrebbero insinuarsi più tardi.




Le applicazioni vengono generalmente compilate prima della distribuzione, in quanto il sito Web utilizza la directory app_code. Quando qualcosa cambia nella cartella del codice dell'app, il server ricompilerà il codice. Ciò significa che è possibile aggiungere / modificare codice con un sito Web al volo.

Il vantaggio di un'app è che non vi è alcuna ricompilazione e quindi i tempi iniziali di avvio saranno più veloci.




Nei progetti di applicazioni Web, Visual Studio necessita di ulteriori file .designer per pagine e controlli utente. I progetti di siti Web non richiedono questo sovraccarico. Il markup stesso è interpretato come il design.




Dipende da cosa stai sviluppando.

Un sito web orientato ai contenuti avrà il suo contenuto che cambia frequentemente e un sito Web è migliore per questo.

Un'applicazione tende ad avere i suoi dati memorizzati in un database e le sue pagine e il codice cambiano raramente. In questo caso è meglio disporre di un'applicazione Web in cui la distribuzione degli assembly è molto più controllata e offre un supporto migliore per i test delle unità.




Sicuramente un'applicazione web, un singolo file DLL e di facile manutenzione. Ma un sito web è più flessibile; puoi modificare il file aspx mentre sei in movimento.




Una delle differenze principali è che i siti Web vengono compilati in modo dinamico e creano assembly in tempo reale. Le applicazioni Web vengono compilate in un unico grande assieme.

La distinzione tra i due è stata eliminata in Visual Studio 2008.




Un "sito web" ha il suo codice in una directory App_Code speciale ed è compilato in diverse DLL (assembly) in fase di esecuzione. Una "web application" è precompilata in una singola DLL.