Creazione di un'app MVC estendibile per più mercati aziendali

1

Supponiamo che tu debba creare un'unica applicazione di e-commerce globale per supportare più mercati in diverse regioni del mondo usando ASP.NET MVC.

Sebbene la maggior parte della logica di business per l'applicazione sia riutilizzabile per diversi mercati, alcuni mercati vogliono implementare le proprie visualizzazioni e logica di convalida lato client a seconda dell'azione del controller chiamata. La logica del controller dovrebbe rimanere la stessa, solo la vista dovrebbe essere modificata a seconda delle esigenze del mercato specifico e forniranno la vista da utilizzare.

In breve, è necessario fornire un modo per rendere MVC estensibile per queste situazioni.

  • Quali consigli può fornire qualcuno su come gestirlo al meglio?

  • Quali sono le migliori pratiche sull'estensibilità con i controller / viste MVC in questo contesto?

  • O è una cattiva idea in generale?

Spero in qualcosa di pulito che riduca il rischio di rompere il resto della base del codice MVC.

    
posta user1431072 23.09.2014 - 23:11
fonte

2 risposte

1

Aspetta, vogliono "implementare la propria [...] logica di validazione lato client", ma non la logica di convalida lato server? Questo sembra un problema importante, per quanto riguarda la sicurezza.

Allo stesso modo, avere una serie di visualizzazioni scritte da terze parti in esecuzione sul tuo server è fuori questione, dal momento che tali visualizzazioni possono contenere codice dannoso.

Ora, se devi consentire ai tuoi clienti di estendere la tua applicazione, devi avere un'architettura di plugin. Un modo è utilizzare MEF . Un altro modo è creare la tua implementazione con AppDomain s.

Puoi trovare un esempio di tale estensibilità qui . Nota: il codice è stato scritto da me ed è coperto dalla licenza MIT.

In entrambi i casi, dovresti fare molta attenzione con le autorizzazioni che concedi al codice personalizzato. Poiché è scritto da terze parti e viene eseguito sui tuoi server, assicurati di aver compreso correttamente (e di testare attentamente) a cosa può accedere il codice e cosa no.

    
risposta data 24.09.2014 - 02:42
fonte
1

Abbandonate completamente le viste lato server e lasciate che il lato server fornisca solo dati (JSON, XML, qualunque cosa sia conveniente, ma non HTML). Il lato client sarà puro HTML e Javascript. Ciò consente ai clienti di presentare i dati come preferiscono senza richiedere alcun codice lato server.

Tuttavia, questa affermazione è problematica:

their own ... client side validation

La convalida sul lato client è per la comodità dell'utente. La validazione deve ancora essere eseguita sul lato server. Un approccio consiste nel consentire loro di specificare convalide in un linguaggio piccolo che può essere interpretato in fase di runtime. Ad esempio, la convalida potrebbe essere limitata alle espressioni regolari su ciascun valore dal lato client. Un'altra possibilità è eseguire il codice in una sandbox in modo che il codice possa funzionare solo sui dati forniti.

    
risposta data 24.09.2014 - 17:29
fonte

Leggi altre domande sui tag