Architettura: per un singolo sito Web da supportare per diversi client

Question

Architettura: per un singolo sito Web da supportare per diversi client

#1 da (4 voti)

5

Ho sviluppato un sistema con un profilo aziendale. Il sistema è costruito usando i servizi WCF, asp.net.

Ora un'altra società vuole usare anche il nostro sistema. E potrebbero aver bisogno di personalizzazione e alcuni dei loro elementi di dati sono diversi. Pertanto, sto pianificando di creare un database separato per la nuova società e di suddividere il livello della logica aziendale.

Ho pensato a diverse opzioni per architettare questo e ho finito con il seguente. Quindi qual è il modo migliore per progettare un sistema di questo tipo.

Approccio A: Esporre i metodi come due diversi servizi WCF uno per ciascuna azienda. Quindi ci sarà un'interfaccia client WCF (IClient) ma due diverse classi di servizio per ogni azienda che le impianta. ClientAService : IClient, ClientBService : IClient.

Problema: Il problema con questo è tutti i miei datacontracts e datamembers sono esposti al client in 2 diversi namespace. (ClientAService.ObjectABC and ClientBService.ObjectABC). Quindi tutti gli oggetti che uso nel sito sono in conflitto. cioè (quando ho una lista di ObjectABC in un'origine dati nelle pagine web, il sito web non capisce se è da ClientAService o ClientBService .

Approccio B: Esporre i metodi come singolo client WCF, ma 2 livelli di business logic diversi. Ma useranno gli stessi datacontracts. Quindi i metodi restituiranno lo stesso tipo di dati.

quindi avrò una classe di servizio

ClientService : IClient

{
public <ObjectABC> Method1(String Companycode)
{
if(CompanyCode == "A")
    return new AbusinessLogic().Method1();
else if(CompanyCode == "B")
    return new BbusinessLogic().Method1();
}
}

Problema: L'unico problema a cui riesco a pensare in questo momento per ogni nuova azienda, ho aggiunto quanto sopra se fosse parte di tutti i miei metodi.

Sono anche aperto a sapere se questo può essere fatto in un modo migliore rispetto alle opzioni indicate.

nota: mi è stato detto che potrebbero esserci altre società da aggiungere in futuro.

c# architecture design-patterns wcf

posta franklins 10.10.2011 - 18:11

fonte

1 risposta

Leggi altre domande sui tag c# architecture design-patterns wcf

Versioni in conflitto di jQuery in Estensioni separate Comprensione dell'applicazione interfaccia binaria (ABI) [chiuso]

score 4 · Accepted Answer

Al momento mi trovo in un problema simile e sono sicuro che sia comune. Ho ereditato un'applicazione che è stata rapidamente sviluppata per un singolo client, tuttavia era ben noto prima che lo sviluppo iniziasse anche che avrebbe dovuto essere altamente personalizzabile per più client che potrebbero esistere in futuro.

I tipici principi YAGNI sono stati applicati ed è stato infuriantemente adattato alle specifiche esigenze del cliente e NON ai requisiti di livello superiore di livello superiore. Fondamentalmente questa era un'interpretazione errata del client EFFETTIVO. Il cliente reale era la società stessa, il team di sviluppo avrebbe dovuto sviluppare un software che soddisfacesse i requisiti aziendali per un prodotto configurabile e personalizzabile. Il cliente è solo il cliente della società a quel punto.

La migliore risposta qui non è quella che può essere risolta nel design di basso livello come stai pensando. Questo è un problema di progettazione e architettura di alto livello . L'approccio migliore consiste nel rivedere il tuo design di alto livello e identificare componenti globali e logiche di business globali che saranno uguali o per lo più simili tra tutti i clienti. Se hai problemi anche a trovare somiglianze di base, allora STOP perché i tuoi nuovi requisiti dei clienti sono probabilmente così diversi da giustificare una singola applicazione.

Una volta isolando la logica e i componenti aziendali comuni, identifica le esigenze individuali e specifiche dei clienti che sono uniche. I requisiti univoci specifici per il tuo cliente attuale possono essere suddivisi in componenti, mentre i requisiti unici per il tuo nuovo cliente possono essere pianificati con requisiti e storie utente.

Ulteriori attività di sviluppo consisterebbero nel trovare contenuti e risorse statici specifici e renderli configurabili e dinamici (ad esempio, testo helper statico / suggerimenti specifici per clienti attuali, e-mail e altri avvisi di messaggi, immagini e loghi specifici, ecc ...) . Questi possono essere impacchettati in bundle di risorse in genere unici per una specifica distribuzione del cliente.

Altri esempi di componenti personalizzati sarebbero diverse funzionalità orientate all'aspetto per diversi clienti, (ad esempio, il Cliente 1 ha bisogno del provider di autenticazione del modulo di accesso, il Cliente 2 ha bisogno del provider di autenticazione Single Sign On LDAP integrato, ecc ...) Selezione di un buon framework e l'architettura che supporta le funzionalità orientate all'aspetto configu- rabile è un buon passo. Anche l'iniezione delle dipendenze / l'inversione dei quadri di controllo sono un buon approccio.

Con un po 'di refactoring e una solida riprogettazione pianificata, un'applicazione esistente su misura per un cliente specifico può essere trasformata in una soluzione personalizzabile che soddisfa le esigenze di molti diversi tipi di clienti.