Disaccoppia il livello oggetto dall'applicazione Windows Form

Question

Disaccoppia il livello oggetto dall'applicazione Windows Form

Naviga le tue risposte

#1 da (2 voti)

3

La situazione:

La mia azienda fornisce un'applicazione Windows Form installata ai nostri clienti.
Questa applicazione client viene fornita in bundle con un oggetto binario (chiamiamolo Objects.dll )
Objects.dll contiene le proprietà dell'oggetto, i campi, le firme dei metodi, ecc.
Objects.dll contiene anche i Contratti di servizio (interfacce), utilizzati dall'oggetto per comunicare con un servizio Web remoto
Il servizio web remoto (chiamiamolo Service.dll ) è ospitato in remoto, insieme a Objects.dll . Implementa i Contratti di assistenza in Objects.dll

Il problema:

Quando Objects.dll cambia in qualsiasi modo (compresi i Contratti di servizio), è necessario inviare un aggiornamento all'applicazione client. Aggiornamenti come questi richiedono un preavviso di 48 ore e una finestra di manutenzione notturna piuttosto pesante. Ciò è doloroso e va contro il nostro credo di sviluppo interno di avere distribuzioni a basso impatto.

La speranza:

Esiste uno strumento / prodotto / servizio che consente un certo livello di disaccoppiamento del livello dell'oggetto dall'applicazione client. Sto immaginando un servizio di individuazione di servizi / oggetti per l'applicazione client con cui comunicare per ottenere il livello dell'oggetto.

È possibile che una soluzione non esista necessariamente. Anche se questo sarebbe meno che ideale, sto anticipando completamente questa soluzione.

design c# architecture .net

posta Tony Morris 01.08.2016 - 23:51

fonte

1 risposta

Leggi altre domande sui tag design c# architecture .net

Impostazione di classe / metodi in modo condizionale Code Review Best practice per nuove applicazioni / Grandi cambiamenti

score 2 · Accepted Answer

Hai bisogno di un altro livello

Quando vedi problemi come questi, è un'indicazione che alla tua soluzione manca uno strato di astrazione. Dovrebbe esserci qualcosa che abbia un'interfaccia fissa, pubblica e un'implementazione privata che isola il chiamante dai cambiamenti sottostanti. Ci sono tre posti in cui puoi metterlo: dove lo aggiungi può dipendere da preoccupazioni del progetto come chi sta per fare il lavoro e il cui budget lo pagherà.

Al termine del servizio

Idealmente, le persone che sviluppano il servizio fornirebbero uno strato di astrazione tra l'API e la logica aziendale, ad es. un'interfaccia, che è abbastanza generica da evitare frequenti cambiamenti. Se un tipo di dati o un nome di parametro cambia nell'infrastruttura sottostante, il servizio isolerebbe il chiamante da tali modifiche mappando gli elementi dell'interfaccia esistenti sulle nuove strutture o delegati. Una nuova interfaccia dovrebbe essere necessaria solo quando ci sono cambiamenti significativi nella funzionalità (nel qual caso dovresti comunque rivedere l'applicazione Windows).

All'estremità client

Se non sono disposti a farlo, puoi aggiungere un livello adattatore sul lato client che avrebbe un interfaccia pubblica fissa e implementazione privata che si occupa delle API del servizio non elaborato. Avresti bisogno di questo adattatore per essere distribuito nello stesso pacchetto che contiene gli aggiornamenti a objects.dll . E idealmente sarebbe costruito come parte della build di integrazione continua per objects.dll per garantire la compatibilità.

Nel protocollo

Se usi un protocollo RESTful, il client può scoprire dinamicamente qualsiasi nuovo elemento di interfaccia usando Interfaccia uniforme .

Se utilizzi un tipo di protocollo JSON, il server e il client possono supportare nuovi elementi di interfaccia tramite digitazione anatra .

Se si utilizza WCF, è possibile utilizzare il versioning lassista per alleviare il problema. In questo modello, la rimozione degli elementi dell'interfaccia esistenti interromperà comunque la soluzione, ma puoi aggiungere nuovi elementi senza romperli.