Re: Hiding Access to Multiple Databases
From: Cristiano Sadun (TAKEcristianoTHISsadunOUT_at_hotmail.com)
Date: 02/26/04
- Next message: Fred: "Re: Interface Ownership"
- Previous message: Gumby: "Re: Design Pattern Newbie Question re: Factory Method"
- In reply to: Shane Mingins: "Hiding Access to Multiple Databases"
- Next in thread: Shane Mingins: "Re: Hiding Access to Multiple Databases"
- Reply: Shane Mingins: "Re: Hiding Access to Multiple Databases"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 26 Feb 2004 13:37:33 +0000 (UTC)
"Shane Mingins" <shanemingins@yahoo.com.clothes> wrote in
news:403d26e4$1@news.iconz.co.nz:
> So are there other possibilities to consider?
There are sevral efforts in data-oriented integration. BEA Liquid Data
is the first coming in mind. I was working some time ago for a company
developing a similar approach, where we developed a conceptual model for
achieving that kind of integration in a quasi-industrial way (or that
was the theory: for a number of reasons the actual implementation turned
out not to be, putting it mildly, that great - mainly for wrong
technological choices, especially XSLT, and design choices :-).
The basic idea is define a layer that contains the "integrated" data
(objects) and abstracts on where exactly such data comes from. It's this
layer responsability to know how and from where actually integrate the
data. Applications then query this layer rather than querying the
original data sources.
In your example, the integration layer would know about the two
databases, when to pick up their customer data and how to merge them in
a single unified class "Customer" - which in turn would be the one
object seen by your application.
The interesting thing is that lots of useful properties of the
integrated data (freshness, ratio of update, caching properties etc) and
the responsabilities of managing them fall almost "naturally" in place
at one of the three levels (integrated layer, integration layer and
application).
Also, the method has some drawbacks (for example, the notion of
"customer" interesting to an application may be overkill for antoher and
performance considerations come around) but in general I still think
lots of "typical" scenarios fit well and gives some improvement in data
reusability.
It may be overkill for very simple scenarios tough.
-- You dont know what to do when you dont know what you're doing. http://space.tin.it/computer/csadun
- Next message: Fred: "Re: Interface Ownership"
- Previous message: Gumby: "Re: Design Pattern Newbie Question re: Factory Method"
- In reply to: Shane Mingins: "Hiding Access to Multiple Databases"
- Next in thread: Shane Mingins: "Re: Hiding Access to Multiple Databases"
- Reply: Shane Mingins: "Re: Hiding Access to Multiple Databases"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|