Come si dovrebbe modellare un oggetto ExchangeService (in ews-java-api) per condividere le connessioni di MS Exchange?

Question

Come si dovrebbe modellare un oggetto ExchangeService (in ews-java-api) per condividere le connessioni di MS Exchange?

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

3

Sto creando un'applicazione che utilizza ews-java-api per connettersi a un server MS Exchange. Una volta che la connessione è autenticata, l'API impone l'uso di ExchangeService oggetto per la ricerca di cassette postali, recupero di mail e lettura del suo contenuto.

Le e-mail vengono lette da diverse classi lungo la linea per analisi e azioni a seconda del contenuto della posta elettronica. Tutte queste classi devono avere bisogno di un'istanza pre-autenticata dell'oggetto ExchangeService.

L'istanza dell'oggetto è ottenuta come -

ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2010_SP2);
ExchangeCredentials credentials = new WebCredentials("emailAddress", "password");
service.setCredentials(credentials);

In futuro potrebbero esserci dei requisiti per aggiungere più classi lungo la linea in base alle esigenze per più funzionalità. Tutti utilizzerebbero la stessa istanza dell'oggetto ExchangeService.

La mia domanda è come dovrei progettare la condivisione dell'istanza di ExchangeService tra tutte queste classi su tutta la linea? Tenendo presente che nessuno dovrebbe inavvertitamente chiamare il metodo "close ()" su quell'istanza, fino al termine di tutta l'applicazione.

A prima vista potrebbe apparire come una sorta di progetto di connessione al database, ma non è così. Questa applicazione viene eseguita periodicamente ogni 5 minuti e si connette al server Exchange, fa il suo lavoro di analisi dei messaggi non letti (con tutte le classi comportamentali) e idealmente dovrebbe chiudere la connessione.

Mi è venuto in mente anche un solo pensiero sul modello singleton, ma il problema di chiamare il metodo "close ()" rimane ancora.

Qualche suggerimento di design per semplificare il sistema?

Grazie in anticipo!

java design-patterns object-oriented-design

posta andromeda 23.08.2015 - 19:30

fonte

2 risposte

Leggi altre domande sui tag java design-patterns object-oriented-design

Distribuire l'applicazione PHP sul servizio clienti indipendentemente dall'ambiente Approccio progettuale all'outsourcing di un socket in una propria discussione

score 1 · Answer 1

Personalmente preferirei dichiarare un'interfaccia che vuoi che i tuoi clienti usino. Inizia subito con ciò che è necessario ora e esponi più funzionalità in un secondo momento.

La tua interfaccia assicurerebbe che il metodo close() non sia disponibile.

L'unica implementazione gestirà la negoziazione con il server e deciderà quando / se chiudere la connessione.

Il resto della tua app ottiene un riferimento all'oggetto usando l'iniezione di dipendenza o il tuo modello Singleton. L'importante è che tu stia mostrando questa interfaccia.

Questo ti dà anche la possibilità di cambiare il modo in cui gestisci le connessioni in futuro, chiudendo automaticamente la connessione quando c'è un periodo di inattività, quindi ristabilendo la connessione su richiesta.

score 0 · Answer 2

Tutte le classi hanno veramente bisogno di accedere all'intero oggetto? Altrimenti, questo sembra un problema di correttezza (ma non in senso negativo), piuttosto che un problema di progettazione. Un approccio è considerare un contratto di codice applicato da un chiamante:

f(g, exchange-object) { 
   /* pre-condition/invariant */
   assert(exchange-object.open() == true);
   g(exchange-object);
   /* post-condition/invariant */
   assert(exchange-object.open() == true);
   }
..
f ( obj-on-the-line.g, exchange-object )
..

Altre informazioni: link