--- Robert McIntosh <[EMAIL PROTECTED]> wrote:
> One of the problems with this is that all of these use different APIs
> and feature sets, so if you wanted a wrapper to accomodate all, you
> would lose some functionality that you probably wanted and thus based
> your choice on.
>
True, and this is often the case anytime you use a wrapper.
> From the client's point of view, one impl may require you to issue a
> query in OQL (like Hibernate) or in JDO-QL (like OJB), or specify a
> query 'name' (like eQ!, similar to a stored procedure in SQL). In other
> words, you probably couldn't just swap out one implementation for
> another without affecting the client code, unless of course you had your
> own (i.e. some Avalon component) that could interpret between the
> different impls.
>
> - Robert
I'm not sure about this.
Say I'm client code and I want a list of products. I know what parameters are
needed, I shouldn't need to know how the query is executed. In other words:
ProductDao product = m_daoManager.getDao("product");
List productList = product.getList(productCategory, color, ... );
Or something like that.
This is really glossing over a lot, but the idea is, the ProductDAO could be
using Torque or eQ! or whatever to get the List. That's not important to the
client code. The client should simply have a contract (interface) with the
DAO. This means crafting a sufficiently complete set of interface methods.
I'm not saying that this would work in all cases, but I do think there are
applications were it is simple enough to do something like this and that there
is a large advantage to it. Perhaps I'm simplifying this too much, but I've
used similiar patterns in several of my applications and found it powerful and
flexible.
jaaron
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]