Design pattern per comportamenti di codice diversi in base a client diversi

Question

Design pattern per comportamenti di codice diversi in base a client diversi

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

1

Nella mia azienda, abbiamo una soluzione composta da un WinForm (multiplo per client) e un'API (uno per client). Questa soluzione viene distribuita su client diversi che richiedono che la soluzione si comporti diversamente in base ai propri desideri. Lo stesso codice base deve supportare le personalizzazioni dell'interfaccia utente (logo del client, visibilità dei pulsanti) e personalizzazioni delle funzionalità (chiamando lo stesso WebMethod con diversi flag).

Attualmente gestiamo questa flessibilità dal lato WinForm avendo una classe Organization che contiene tutte queste personalizzazioni (flag). L'API è totalmente indipendente dal client. Pertanto, i metodi di WinForm hanno questo aspetto:

this.Logo = CurrentOrganization.LogoImage;

API.GetProducts(Organization.UsesPagination);

In passato, avevamo direttive di compilazione condizionale sparse nel codice:

#IF CLIENT_A
    API.GetProductsWithPagination();
#ELSE
    API.GetProducts();
#ENDIF

Oggi abbiamo una singola zona con quelle direttive di build condizionali che, in base alla configurazione di build, istanzia la classe Organization richiesta. In seguito, non ci sono più IF, passaggio parametri.

Sono un po 'preoccupato che questo non sia il miglior design o la soluzione più gestibile . Ho studiato il pattern di stato ... Suppongo che Organization sia il mio oggetto di strategia, poiché indica ad altri metodi come dovrebbero comportarsi attraverso le bandiere.

C'è un un modo migliore ?

Memorizzazione delle configurazioni su una tabella DB? (richiede più richieste all'API, che costa tempo)
Memorizzazione delle configurazioni su un file * .config? (qualcuno può facilmente modificare il comportamento dell'app modificando il file)

c# architecture design-patterns

posta DiAlex 21.07.2015 - 16:10

fonte

3 risposte

1

Penso che tu sia quasi arrivato. Stai ottenendo lo stato e la strategia. Il modo di selezionare potrebbe essere Fabbrica o Builder , magari leggendo un file di configurazione o un database proprio come hai indicato.

Alla fine dipenderà dalle tue esigenze, ma la strategia combinata con la Fabbrica o un Pattern Builder per creare l'oggetto che contiene la giusta politica sulla creazione ti aiuterà a sbarazzarti delle direttive dei build condizionali.

risposta data 21.07.2015 - 16:24

fonte

0

Mi impegnerei per la progettazione basata sui dati. Ciò significa che il tuo codice è guidato da dati specifici del cliente. Questi dati possono essere memorizzati nel database o nei file di configurazione o qualsiasi cosa ti si addice meglio. In questo modo non devi creare binari diversi per ogni cliente con le direttive di costruzione condizionale.

Nei casi in cui è necessario un comportamento diverso per i diversi clienti, è possibile cercare il comportamento desiderato dai dati del cliente e utilizzare lo schema della strategia cambiarlo durante il runtime.

risposta data 21.07.2015 - 18:27

fonte

Leggi altre domande sui tag c# architecture design-patterns

Qual è il modo più veloce e più gestibile per implementare l'interrogazione SQL di variabili C ++ disparate? Test del modulo del sito web [chiuso]

score 1 · Accepted Answer

La prima cosa che dovresti controllare è quante righe di codice ha una tipica implementazione di classe Organization e come è strutturata. Se ha meno di 100 righe di codice e la classe consiste principalmente di proprietà che forniscono alcuni flag o dati, non preoccuparti. Se ha più di 2000 e contiene molte logiche di business, dovresti considerare di dividerlo in parti più piccole o di generalizzare alcuni flag o proprietà. Tuttavia la tua classe Organization può ancora essere una facciata per i dati di configurazione.

Storing configurations on a DB table? Storing configurations on a *.config files?

Anche se si utilizza una tabella DB o un file di configurazione, sarà comunque necessario un oggetto Organization che carichi la configurazione dalla tabella DB o dal file di configurazione in memoria per fornire tali dati al resto del programma. Ciò consente a te o a un amministratore oa qualcun altro di aggiungere nuove organizzazioni o di modificare le funzionalità delle organizzazioni esistenti senza realmente modificare il codice. Quindi usa una tabella DB o un file di configurazione se hai quel requisito, non perché vuoi ottenere una migliore manutenibilità.