Come organizzi le tue applicazioni ASP.NET MVC 3? [duplicare]

Servire js, css e altre cose statiche da una DLL richiede un disastro di prestazioni se il tuo sito riceve molto traffico. Un progetto MVC regolare consentirebbe a IIS di gestirli, il che renderebbe molto più efficiente l'uso della memorizzazione nella cache sia sul client che sul server.

Il motivo principale per cui tutto è racchiuso in una dll sembra essere puramente per comodità di implementazione. Una dll è solo una povera forma di packaging imho. La differenza tra la decompressione di un file e la semplice copia di una singola DLL è così piccola, non vedo abbastanza valore nel complicare il processo di sviluppo su di esso.

Di solito vedo le mie app MVC come l'estensione stessa e non come qualcosa che deve essere estensibile. L'applicazione MVC è principalmente configurazione, colla e livello di applicazione. La maggior parte del mio codice è isolata in un assembly del modello di dominio.

Aggiunto per la nuova soluzione:

Probabilmente rendi più semplice la tua attività se fai in modo che l'aggiornamento venga eseguito da una piccola applicazione di servizio separata. In questo modo potresti avere meno problemi nell'aggiornare materiale, potenzialmente colpire gli assembly in cui risiede il servizio di aggiornamento stesso, ecc.

Forse farà una piccola applicazione virtuale. Ciò potrebbe inoltre rendere più facile gestire scenari di piccole web farm e / o pubblicare avvisi temporanei "sul sito in fase di aggiornamento" ecc. Il rollback è probabilmente più semplice anche se lasci intatta la versione precedente del tuo sito mentre passi.

I progetti di Visual Studio hanno alcune opzioni di packaging e implementazione che possono aiutarti a iniziare. Sono fondamentalmente file zip con alcuni metadati aggiunti. Puoi utilizzarli per distribuire le tue app utilizzando il motore di Web Deploy che puoi installare su un server web (questo potrebbe salvarti dallo scrivere questo servizio tu stesso).

(non hai ancora esperienza di distribuzione sul Web, quindi non posso dirti di più)

La distribuzione più semplice sarebbe semplicemente comprimere la posizione del sito Web e fornire loro istruzioni su come associare una directory virtuale ad essa in ciascuna versione di IIS che supportate. Quando si forniscono aggiornamenti al software, fare in modo che eseguano il backup del percorso di installazione corrente, copiando la cartella, prima di copiare gli aggiornamenti rispetto all'originale. In questo modo, se ci sono problemi, possono tornare alla versione precedente. È facile, funziona e non costringi i tuoi clienti più esperti a fare le cose in un certo modo.

Aspettare che gli utenti sappiano come seguire le indicazioni, come l'avvio e l'arresto del server Web, quando si installa o si aggiorna un sito Web, quando eseguono un sito Web, non è una richiesta irragionevole. Ti farà risparmiare molto tempo nella manutenzione del software. Non riceverai molte chiamate di assistenza se le tue istruzioni sono buone. Anche se ricevi chiamate di assistenza, la risoluzione del problema è rapida e prevedibile, perché hai a che fare solo con una directory virtuale di base e un albero di file, non con un'installazione personalizzata.

Aggiornamento:

Fornire permessi di scrittura a una directory con autorizzazioni di esecuzione, che è quello che ci sarebbe richiesto per far caricare il file zip dall'interno dell'applicazione, è una violazione della sicurezza che aspetta di accadere.

Se avessi una sorta di soluzione pacchettizzata (specialmente se fosse stata installata tramite l'applicazione web), avresti molti scenari diversi da risolvere (ad esempio permessi, firewall, bug nel processo di installazione, ecc.)