The answer would be very broad, so I would suggest you to use the:
- DAO ( Data Access Object ) design pattern to abstract the source of the data ( database or webservice )
- Strategy to abstract the algorithm by which the data is merged ( when both sources are available and one there is only one )
- And finally State design pattern to change the way your app works depending on which source is available.
- All thie wrapped ( why not ) in a nice Facade
I'll write some pseudo code in a moment for this.
EDIT It was quite a lot of pseudo code though.
This psuedo code has similar syntax as UML and python, I hope is it not boring:
// the data implements one interface
Data {interface}
// and you implement it with DatabaseData
DbData -> Data
...
// Or WebServiceData
WsData -> Data
...
// -- Dao part
Dao {interface}
+ fetch(): Data[]
// from databae
DatabaseDao -> Dao
- data : Data[0..*]
// Query database and create dbData from rows...
+ fetch() : Data[]
self.status = "Not ok"
self.status = connectToDb()
if( self.status == ok ,
performQuery()
forEach( row in resultSet,
data.add( DbData.new( resultSet.next() ) )
)
disconnect()
)
...
// From webservice
WebServiceDao -> Dao
- data : Data[0..*]
// execute remote method and create wsData from some strage object
+ fetch(): Data[]
remoteObject: SoapObject = SoapObject()
remoteObject.connect()
if( remoteObject.connected?(),
differentData: StrangeObject = remoteObject.getRemoteData()
forEach( object in differentData ,
self.data.add( WsData.new( fromElement ))
)
).else(
self.status = "Disconnected"
)
....
// -- State part
// abstract the way the data is going to be retrieved
// either from two sources or from a single one
FetcheState { abstract }
- context : Service
- dao : Dao // used for single source
+ doFetch() : Data[] { abstract }
+ setContext( context: Service )
self.context = context
+ setSingleSource( dao: Dao)
self.dao = dao
// Fetches only from one dao, and doesn't quite merge anything
// because there is only one source after all.
OneSourceState -> FetcheState
// use the single dao and fetch
+ doFetch(): Data[]
data : Data[] = self.dao.doFetch()
// it doesn't hurt to call "context's" merger anyway
context.merger.merge( data, null )
// Two sources, is more complex, fetches both daos, and validates error
// is one source had error, it changes the "state" of the app ( context )
// so it can fetch from single source next time
TwoSourcesState -> FetcheState
- db : Dao = DatabaseDao.new()
- ws : Dao = WebServiceDao.new()
+ doFetch() : Data[]
dbData : Data[] = db.doFetch()
wsData : Data[] = ws.doFetch()
if( ws.hadError() or db.hadError(),
// changes the context's state
context.fetcher = OneSourceState.new()
context.merger = OneKindMergeStrategy.new()
context.fetcher.setContext( self.context )
// find out which one was broken
if( ws.hadError(),
context.fetcher.setSingleSource( db )
)
if( db.hadError(),
context.fetcher.setSingleSource( ws )
)
)
// since we have the data already
// le'ts merge it with the "context's" merger
return context.merger.merge( dbData, wsData )
// -- Strategy part --
// encapsulate algoritm to merge data
Strategy{ interface }
+ merge( a: Data[], with : Data[] )
// One kind doesn't merge too much, just "cast" one array
// because there is only one source after all.
OneKindMergeStrategy -> Strategy
+ merge( a: Data[], b : Data[] )
mergedData : Data[]
forEach( item, in( a ),
mergedData = Data.new( item ) // take values from wsData or dbData
)
return mergedData
// Two Kinds merge, encapsulate the complex algorithm to
// merge data from two sources.
TwoKindsMergeStrategy -> Strategy
+ merge( a: Data[], with : Data[] ): Data[]
forEach( item, in( a ),
mergedData : Data[]
forEach( other, in(with ),
WsData wsData = WsData.cast( item )
DbData dbData = DbData.cast( other )
// add strange an complex logic here.
newItem = Data.new()
if( wsData.name == dbData.column.name and etc. etc ,
newItem.name = wsData+dbData...e tc. etc
...
mergedData.add( newItem )
)
)
)
return mergedData
// Finally the service where the actual fetch is being performed.
Service { facade }
- merger: Strategy
- fetcher: FetcheState
// init the object with the default "strategy" and the default "state"
+ init()
self.fetcher = TwoSourcesState()
self.merger = TwoKindsMergeStrategy()
fetcher.setContext( self )
// nahh just let the state do his work.
+ doFetch() : Data[]
// fetch using the current app state
return fetcher.doFetch()
Client usage:
service : Service = Service.new()
service.init()
data : Data[] = service.doFetch()
Unfortunately it looks a bit complex.
OOP is based a lot in polymorphism.
So in Dao, you let the subclass fetch data from what ever place and you just call it dao.fetch()
In Strategy the same, the subclass performs one algorithm or the other ( to avoid having a lot of strange if's else's switch's etc )
With State happens the same thing, instead of going like:
if isBroken and itDoesntWork() and if ImAlive()
etc etc you just say, "Hey this will be the code one there are two connections and this is when there is only one.
Finally facade say to the client "don't worry I'll handle this"