Sito web multiutente per il progetto MVC: uno o più soluzioni?

Question

Sito web multiutente per il progetto MVC: uno o più soluzioni?

#1 da (3 voti)
#2 da (1 voti)
#3 da (0 voti)

3

Stiamo avviando un nuovo progetto MVC 5 che alla fine consisterà di 4 siti Web a seconda del tipo di utente:

Uno interno, per i dipendenti della società.
Uno per agenti, appaltatori indipendenti che lavorano per la società.
Uno per i venditori esterni.
Uno per i clienti, che potrebbe essere uno qualsiasi dalle loro case.

Il sito web interno avrà una funzionalità notevolmente maggiore rispetto a tutti gli altri, e dato che sarà accessibile solo dai dipendenti, verrà mantenuto in una rete privata. La soluzione è strutturata in questo modo:

Un progetto Dati in cui vengono mantenute le classi del modello. Questo è stato fatto utilizzando il Database di Entity 6 First.
Un progetto Risorse con stringhe e immagini.
Un progetto Web con gli elementi MVC: controller e viste, oltre a CSS / JS, ecc.

Dato che un sito web sarà interno mentre l'altro sarà accessibile tramite un IP pubblico, il mio primo pensiero è stato quello di avere due soluzioni separate: una per il Web interno e una per tutte le altre (cambiando tra le visualizzazioni in base alla registrazione utente), distribuendoli su un altro server. Il lato negativo che vedo è che ci sarebbe un sacco di codice duplicato tra le soluzioni: non solo il progetto Data dovrebbe essere molto simile o addirittura lo stesso, le risorse e le viste avrebbero un sacco di cose comuni.

Mi chiedo se sarebbe più sensato avere una sola soluzione con un progetto Data, un progetto Risorse e poi progetti InternalWeb e ExternalWeb. Forse anche avendo tre progetti diversi invece di ExternalWeb: AgentsWeb, CustomerWeb, SalesWeb.

Ho poca esperienza con le applicazioni MVC mentre li sto distribuendo, quindi mi piacerebbe sapere in che modo sono viste le migliori pratiche per questo tipo di situazione.

c# projects-and-solutions asp.net asp.net-mvc mvc

posta Antrim 14.10.2015 - 13:28

fonte

3 risposte

Leggi altre domande sui tag c# projects-and-solutions asp.net asp.net-mvc mvc

Riutilizzare un'interfaccia o un metodo di concatenazione Come tenere traccia delle attività tecniche con BDD?

score 3 · Answer 1

OK, penso che manchi un livello che renderebbe il tuo problema più facile da risolvere

Avrei:

Livello dati - EF, sql client qualunque
Repository - nasconde il livello dati
Service Layer / Business Logic - esegue il lavoro effettivo
Servizio di autenticazione
Livello applicazione: sito Web MVC
- controller: servizi di chiamata
- viste
- visualizza modelli
- etc

Separando la tua logica aziendale da entrambi i dati e il livello dell'applicazione sei libero di utilizzarlo su più livelli di applicazione. Classicamente questo sarebbe un sito Web e un'applicazione di Windows Form, ma nel tuo caso potrebbe essere un sito pubblico e un sito web interno.

Analogamente al livello di autenticazione, dividendolo puoi essere molto più flessibile con i tuoi diritti utente. Controllo nel controller dei siti MVC, prima di chiamare un servizio, o nel servizio stesso, o entrambi.

Nel complesso, riducendo la quantità di codice nel tuo sito web, riduci la quantità di duplicazione del codice richiesta se devi avere più di una versione del sito web.

Per quanto riguarda il fatto che avere più siti web rispetto a un sito web muti-role è la scelta migliore. Direi che avere un singolo sito Web è il più semplice per gli utenti, ma avere due, con le funzioni fondamentali dietro un firewall è più sicuro e più facile dimostrare la sicurezza

score 1 · Answer 2

La struttura può dipendere dal servizio dei tuoi server.

Se fossi in te, per una rapida risposta potrei controllare prima le pagine dell'interfaccia utente che hanno molte parti comuni o meno. Se le pagine, le funzioni e le caratteristiche complessive sono diverse per ruoli, non è necessario preoccuparsi di creare server multipli. Hai molte scelte e anche tu puoi usare solo un DB con più server. A volte separare i server è meglio in termini di gestione, tolleranza agli errori, sicurezza e sviluppo.

Ma se ci sono molte pagine comuni tra i ruoli, ti consiglio di implementare la gestione di ruoli e abilità da parte del cliente in modo che il server possa visualizzare pagine diverse in base a ruoli o abilità. È inoltre possibile separare le pagine per porta o URL per impedire la duplicazione del codice. Potrebbe essere migliore in termini di gestione del codice. Si può scegliere questo significa se si stima futuri requisiti aggiuntivi enormi. Ma la debolezza è il beneficio del primo. Ad esempio, se devi servire server importanti come il pagamento, faresti meglio a saperlo.

score 0 · Answer 3

È difficile dare una risposta ferma senza sapere quanta funzionalità verrà condivisa tra ciascun sito Web.

Tuttavia, si desidera sempre evitare la duplicazione il più possibile.

Vale la pena di seguire il suggerimento di Ewan: creare un livello dati separato che gestisca tutti gli accessi al database e la logica aziendale. Vale sempre la pena farlo, indipendentemente da come sarà progettato il tuo front end.

Successivamente, analizzerei la creazione di un front-end singolo e implementerò le autorizzazioni degli utenti: aggiungere controlli per verificare se l'utente che ha effettuato l'accesso è un agente, venditore o cliente, quindi regolare le informazioni visualizzate a seconda di ciò.

puoi sempre suddividere le pagine in più file e includerli a seconda del livello dell'utente. Ad esempio, per un modulo Crea cliente, procedi come segue: - CreateCustomer.cshtml: contiene tutti i campi generici disponibili per tutti gli utenti - CreateCustomer_agent.cshtml: contiene campi aggiuntivi per gli agenti - CreateCustomer_sales.cshtml: contiene campi aggiuntivi per venditori

Non dimenticare che puoi anche cambiare il _Layout.cshtml usato su ogni pagina, così puoi cambiare pragmaticamente il file _Layout.cshtml usato, cambiando così il menu usato, o anche l'intero aspetto dell'applicazione.