Come dovrei refactoring in modo che la responsabilità per un servizio di geocoding sia condivisa in modo appropriato?

Question

Come dovrei refactoring in modo che la responsabilità per un servizio di geocoding sia condivisa in modo appropriato?

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

0

Per prima cosa, un po 'di background. Ho un'applicazione che richiede l'uso di diversi fornitori di geocodifica esterni che non controllo. Utilizza un livello di servizio centrale all'interno dell'applicazione per inviarlo al fornitore appropriato.

Ho un numero di classi che sono organizzate in questo modo:

GeocodingService : responsabile di inviare una richiesta per geocodificare qualcosa a un fornitore appropriato.
- Ha un metodo pubblico, geocode , che accetta un GeocodingService :: Request e restituisce un GeocodingService :: Response .
- Ogni risposta include: la latitudine della query geocoded, la longitudine della query geocoded e un elenco di componenti di indirizzo per l'indirizzo in cui è stata trovata la query (ad esempio, un componente di indirizzo per "123", uno per "Principale Street ", uno per" Paris "e così via).
GeocodingService :: AddressComponent : un singolo segmento di un indirizzo che contiene il nome del segmento, la sua abbreviazione e i suoi tipi. Ad esempio, la Francia ha un nome di France , un'abbreviazione di FR , ed è un country e un political segmento.
- AddressComponent è responsabile di verificare che i tipi con cui un'istanza è impostata non siano al di fuori dei limiti di determinati tipi di tracciamento.
Indirizzo : modello di dominio per gli indirizzi, contenente sia un indirizzo di posta preferito (un elenco di linee di stringa) sia un elenco di componenti di indirizzo (un elenco di GeocodingService :: AddressComponents).

La mia domanda è: dove dovrebbe vivere AddressComponent - come classe di servizio (come fa ora), o con i miei altri modelli di dominio?

Se vive nel servizio , la vita è semplice. Ma ciò sembra sbagliato, perché ora un modello di dominio deve dipendere dalla definizione di un indirizzo di un servizio, e sembra che dovrebbero essere indipendenti.
Se vive come un oggetto dominio completo , allora questo non significa che il servizio ora è abbinato a un oggetto dominio? Anche questo sembra indesiderabile.

Come posso risolvere questa impasse?

refactoring

posta John Feminella 19.04.2012 - 06:47

fonte

2 risposte

Leggi altre domande sui tag refactoring

Implementazione della classificazione del testo Formato di archiviazione persistente per dati aggiornati (aggiornati + letti)

score 1 · Answer 1

Solo perché AddressComponents viene dedotto dai dati esterni forniti da un servizio non significa che non sono oggetti di dominio di prima classe nel modello di dominio. Immagina di scrivere un'altra applicazione nello stesso dominio: non sarebbe bello poter riutilizzare il tuo dominio senza doversi preoccupare dei Servizi? Voglio dire, la nuova applicazione potrebbe ottenere dati AddressComponent da qualsiasi luogo, ad esempio il proprio database. Un AddressComponent non sarebbe necessariamente collegato a un servizio.

Quindi sceglierei l'opzione 2, e se sei preoccupato per il tuo servizio che crea un'istanza di un oggetto dominio, forse potresti introdurre un altro oggetto che crea la creazione, ad esempio una fabbrica.

score 0 · Answer 2

È necessario un adattatore o un generatore per costruire l'oggetto dominio Indirizzo da GeocodingService :: AddressComponent. Questo è il punto in cui accoppi i componenti senza stringere, mantenendo la separazione di preoccupazioni e coesione.