Re: How to do non dependence on database vendor?
- From: "Bjorn Abelli" <bjorn_abelli@xxxxxxxxxxxxxxxxxxxxx>
- Date: Sun, 15 May 2005 21:54:05 +0200
"Brett" <wrote...
> "Bjorn Abelli" wrote...
>> You could actually get away with only a single proxy if you use
>> reflection... ;-)
>>
>> Through reflection you can dynamically load the ADO.NET-driver, using
>> some kind of "ini-file" to let the proxy know where to look for it, which
>> classnames are used for the driver, connection-strings, etc.
>
> However, there would be a performance hit to using Reflection. Also, I
> like the interface approach. Everything in classes that you can
> instantiate. Would that better than an INI file and Reflection...both of
> which are going to be slower?
>
> The interface approach seems more scalable and contained.
I would rather say that both approaches really are heavily based on
interfaces, though with reflection, your implementation would be more
flexible, as you wouldn't even need to implement a new concrete proxy for
each new DB.
For the performance hit, I would say that it possibly could be neglectable,
as it could be "reflected" at only the startup of the application, but that
also depends on the design of the rest of it...
>> I would still look at the "data layer" from both perspectives, i.e. from
>> the "Business Perspective" and from the "DB-perspective".
>>
>> What do I need to store persistent?
>>
>> That would make up a layer between the business logic and the data layer,
>> focusing on storing and retrieval of the explicit data, but free from
>> other considerations in the business logic, and free to make use of
>> different DB-approaches. Though it would be dependant on the rest of the
>> business logic, it frees the layer from the details of SQL, if you in the
>> future want to make use of another DB than those supporting SQL.
>
> I'm still not seeing what exactly this other abstraction layer is. I
> understand the use of a proxy (interface) and how that allows me to
> support multiple databases using standard SQL. Say now I have another
> database that uses non standard SQL. I add another proxy class for it.
> Now what exactly needs to be done on this other higher level abstraction
> layer to support the non standard SQL? Perhaps example with psuedo code?
Well, you have possibly already thought of it, but included it into your
business logic. This kind of layer is often considered a part of that layer
as it's so dependent on the classes in the business logic.
What I mean is simply an interface to the storage/retrieval of the data.
This can be done in several ways. One way is similar to the proxy variant
above, but foremost the use of a distinct interface for this, makes it
easier to change it afterwards anyway.
In short...
interface MyBusinessStorageManager
{
ArrayList GetCustomers();
ArrayList GetProducts();
ArrayList GetOrders();
boolean SaveOrder(Order o);
...
}
....which in turn is implemented by a class that *calls* the classes with the
SQL or others...
// Bjorn A
.
- Follow-Ups:
- Re: How to do non dependence on database vendor?
- From: Brett
- Re: How to do non dependence on database vendor?
- References:
- How to do non dependence on database vendor?
- From: Brett
- Re: How to do non dependence on database vendor?
- From: Bjorn Abelli
- Re: How to do non dependence on database vendor?
- From: Brett
- Re: How to do non dependence on database vendor?
- From: Bjorn Abelli
- Re: How to do non dependence on database vendor?
- From: Brett
- How to do non dependence on database vendor?
- Prev by Date: Re: How self-aware can an item in a complex nested class be?
- Next by Date: editing data in a datagrid
- Previous by thread: Re: How to do non dependence on database vendor?
- Next by thread: Re: How to do non dependence on database vendor?
- Index(es):
Relevant Pages
|