Differenza tra 'Sito Web' e 'progetto' in Visual Studio

Question

Eventuali duplicati:
ASP.NET: Web Site or Web Application?

ho notato che v'è chiaramente una differenza di quello che si ottiene quando il fuoco Visual Studio 2008 e scegliere 'Nuovo progetto' -> 'Applicazione Web ASP.NET' invece di 'Nuovo sito Web' -> 'Sito Web ASP.NET'. Ad esempio, se scegli "Progetto", puoi compilare il file .dll e ogni pagina riceve un file di codice .aspx.designer.cs.

1) Perché abbiamo questi due diversi tipi di progetto?

2) Quale preferisci?

3) Perché dovrei sceglierne uno rispetto all'altro?

4) Qual è l'accordo con i file * .aspx.designer.cs?

Answer 1

1) Il modello "sito Web" è stato introdotto con ASP.NET 2.0, il modello "web application" era il tipo di progetto del framework .net originale. Entrambi hanno usi diversi (vedi sotto).

2) Dipende dal contesto. Un buon esempio è se si vende un prodotto software, si potrebbe desiderare di utilizzare un progetto di "web application" perché si presta naturalmente a codice compilato in modo pulito.

3) Vedere sopra, preferenza personale, caratteristiche di manutenzione. Una cosa interessante che un "sito web" ti consente di fare in modo che ti porti in un sacco di problemi sta apportando modifiche arbitrarie al file code-behind (tipicamente un * .cs o * .vb) nel blocco note mentre il sito web è in esecuzione.

4) Il file designer.cs viene utilizzato per memorizzare il codice generato automaticamente. "Questo codice è stato generato da uno strumento."

• MSDN Article describing the differences
• Similar stackoverflow question

Answer 2

hanno scopi diversi.

Un sito Web è un sito con contenuti che è probabile che cambi nel tempo, cioè le pagine stesse cambieranno. Non esiste un vero file di progetto e il sito viene implementato semplicemente come un insieme di file.

Un'applicazione è un sito in cui il contenuto è solo l'applicazione, la parte dinamica sarà principalmente in archivio persistente come un database. Avrà una logica più complessa dal momento che è probabile che rappresenti un insieme di moduli per l'immissione dei dati tanto quanto un mezzo per esaminare il contenuto. Ha un file di progetto per controllare più strettamente la sua configurazione e il suo codice distribuito come una DLL compilata.

Answer 3

1. All'inizio c'era un progetto di applicazione Web (si comportava in modo simile al progetto corrente sito web). Lo hanno cambiato per riflettere ciò che alcuni utenti hanno richiesto. Tuttavia, le persone volevano che le vecchie funzionalità tornassero in modo da reintrodurre il progetto del sito Web che si comporta come il progetto di applicazione Web originale.

2. I - e il mio posto di lavoro - preferiscono il progetto di sito Web

3. Ci piace che i file del sito web sono i file nel file system (non è necessario aggiungere manualmente)

4. Nessuna idea

Ecco due articoli che ho trovato su entrambi:

http://damieng.com/blog/2008/02/07/web-site-vs-web-application

http://www.dotnetspider.com/resources/1520-Difference-between-web-site-web-application.aspx

Nota: Un sacco di problemi con i siti web sono stati risolti con il progetto di distribuzione Web

Aggiornamento: Risolto il punto 1, un'applicazione Web era lì prima

Answer 4

Non duplicherò la definizione del 2, dal momento che è appena arrivata una risposta.

Quindi perché utilizzare uno sull'altro?

Sito Web consente di trattarlo come un sito ASP PHP o classico, in cui è possibile apportare modifiche in linea che hanno effetto immediato.

Pro

• È possibile effettuare modifiche al sito giusto sul server web
• Distribuzione è semplice come la copia della cartella

Contro

• Se sei non apportando le modifiche direttamente sul sito live, puoi entrare in problemi di gestione dei cambiamenti, in cui ti dimentichi di mantenere tutto te stesso r file in sincronia
• È possibile ottenere gli errori di sintassi di runtime visualizzati agli utenti finali, dal momento che l'unico modo per controllare è quello di eseguire manualmente ogni pagina

Web Application consente di trattare più simile a come si farebbe un desktop applicazione: è disponibile uno distribuibile compilato sulla macchina.

Pro

• Chiaro, change management strutturato. Non puoi mescolare accidentalmente il codice da due versioni differenti. Questo può essere importante quando ci sono 2 persone coinvolte: una che scrive il codice e l'altra responsabile di mettere i file sul server.

• Perché si compila sulla vostra macchina, tutto diventa Sintassi verificata a quel punto *

Contro

• distribuzione è un po 'più coinvolto poi semplicemente copiando la cartella dal vostro sviluppo macchina. Tuttavia, l'utilizzo del comando "Pubblica" semplifica enormemente il processo di compilazione e raccolta dei file da copiare sul server web.

• Tutte le modifiche devono essere fatte sulla vostra macchina, compilato, e tutta una nuova versione inviati al server web *

* L'aspx/file html sono solo la sintassi verificato se si attiva questo su nelle tue opzioni di costruzione però. È anche possibile modificare questi file sul server a meno che non siano compilati nel progetto.

Answer 5

I siti sono il modo originale .NET di fare web dev. Nella mia esperienza sono estremamente problematici poiché mancano una definizione di progetto che non possono essere riutilizzati e hanno problemi con la codifica modulare, hanno problemi con l'integrazione di TeamSystem e il namespacing. Il legame uno-a-uno con un dominio e la mancanza di un'astrazione editoriale reale creano problemi di manutenzione lungo la linea.

L'antico "classico" modo ASP di! Codebehind è un problema serio perché compromette nuovamente il riutilizzo e il test del codice e i vantaggi spesso citati di consentire hot fix, se mai richiesto, sono in realtà un segnale enorme che si ha un processo di sviluppo fallito. La possibilità di eseguire l'hotfix è ovviamente meglio che non essere in grado di farlo, ma è qualcosa che non si desidera invocare.

Si potrebbe dire che i problemi con il modello di sito web sono stati abbastanza grandi che MS ci ha dato invece applicazioni web. Personalmente non li userei mai per qualcosa al di là del codice demo ... no in realtà non lo farei nemmeno.

Answer 6

3) I progetti WebApplication sono realizzabili da MSBuild. I siti Web non lo sono (senza un sacco di ritocchi). Se usi TeamSystem con build automatici, questa è la strada da percorrere.

Answer 7

C'è poca differenza e consiglio vivamente di utilizzare il modello Sito Web.

La differenza principale è per un sito Web, alcuni file devono essere inseriti in determinate directory (i file di codice devono essere inseriti nella directory "App_Code"), oltre a ciò, è piuttosto semplice.

Se avere codice compilato per la distribuzione è importante per te e vuoi una singola DLL (contraria alle diverse che vengono create quando si esegue una normale pubblicazione per un sito Web), allora si vorrà ottenere questo -on: http://msdn.microsoft.com/en-us/asp.net/aa336619.aspx

Answer 8

La più grande differenza che nessuno ha mai menzionato (eccetto che viene toccata da Annakata) è che con il modello in cui tutto è compilato in una singola DLL, si ha il controllo completo sulle classi generate dall'applicazione. Sapete dove sono e possono sempre farvi riferimento da qualsiasi altra parte dell'applicazione.

Con il modello a pagina singola, non è possibile farlo. Devi aggirarlo creando classi "stub" nella directory AppCode e ereditando quelle nelle tue pagine, ma anche quella non è l'ideale, e aggiungi complessità.

Se si sta tentando di sviluppare un sito dinamico e complesso, in cui si caricano dinamicamente molti controlli utente in fase di esecuzione in base al contenuto, ci si troverà davvero di fronte a questa roba. Quindi, le differenze sono dolorosamente chiare, quindi gran parte del nostro sviluppo si è arrestato su ASP 1.1 fino a quando non siamo riusciti a tornare allo stesso modello in seguito.

Nich

Answer 9

Se il vostro lavoro ha bisogno di sfruttare le caratteristiche del linguaggio oo (gerarchie di classi, spazi dei nomi), o se avete bisogno di riutilizzare il codice comune tra i progetti (accesso ai dati, librerie di classe, ecc), allora il progetto di applicazione web è il unica strada da percorrere

Il sito web del progetto (l'indizio è nel nome) è solo veramente buono per non complessi 'brochureware' siti (in cui le pagine sono costituiti da contenuti statici), contro i web applicazioni.

Answer 10

Le risposte semplici sono i seguenti:

1. Nuovo Sito Web - crea codice dietro le pagine che vengono compilati nel server quando viene richiesta la pagina.
2. Nuovo progetto Web: crea pagine precompilate in uno o più assiemi (anche intero sito) e distribuito sul server.

Scenario n. 1 - Se un hacker ottiene i file code-behind, vengono visualizzate tutte le password del database. Queste pagine sono compilate nel momento in cui vengono richieste. È possibile scegliere di precompilare tutto in un grande assieme. In caso contrario, c'è più carico sul server.

Scenario n. 2: se un hacker ottiene i vostri assiemi, verranno offuscati. Le assemblee offuscate sono più difficili da decifrare. Questi assembly sono precompilati, riducendo così il carico sul server.

Per maggiori informazioni:

Introduction to Web Application Projects

Answer 11

Parlando per esperienza con entrambi: "Siti Web" sono utilizzati in cui non esiste una metodologia di test sul posto, nessun server CI, e una cultura che incoraggia e promuove " aggiornamento rapido "a pagine specifiche regolarmente. Le "Applicazioni Web" sono lo standard di fatto in cui vengono seguite metodologie software corrette e vi è un test di unità (se non completo TDD) e un server CI con l'accento sulla scrittura di codice pulito e individuazione dei bug prima che sorga la necessità di una "correzione rapida".