From: "Weirich, James" Date: 2004-01-13T00:24:12+09:00 Subject: Re: Database applications and OOness > right. but every dbms binding has a different basic api. Why this > useless duplication? > (Probably that may be useful, and I'm just too stupid to understand > why) I'll try to explain some of the rationale behind the DBI implementation. First, let's examine the layers involved. The DBMS API layers is provided by the DBMS itself. This is generally a C language API that must be adapted to Ruby through a library. Ruby-postgres-0.7.1 is such a library. It adapts the PostgreSQL C API to Ruby. There are similar libraries for other DBMS. Sometimes the API is wrapped in a thin OO veneer. Sometimes additional functionality beyond the C API is provided. The DBD level uses the native API to provide a standard DB protocal to the rest of the DBI code. If a Ruby-callable version of a native API didn't exist, then the DBD would have to be written (at least in part) in C. Finally, the DBI level contains the common code used to implement the abstract DBI interface. Can a user use the DBD directly and skip a level? Yes, but I don't think they will find the DBD interface nearly as nice to use as the DBI interface. Could the DBD and native interfaces be merged? Yes. In fact, I would encourage those who provide a native DBMS interface to consider providing a DBD interface as well. This would be similar to the Java world where it is generally the responsibility of the DBMS vender to supply the JDBC drivers. Could the DBI and DBD levels be merged? Yes, but that would require each DBD to duplicate a lot of code that exists in the DBI, obviously not a good thing. Also, a merged DBI/DBD level would be much more difficult for a vender to supply than a relatively straight-forward DBD library. I think it remains a good idea to keep the DBD and DBI separate. If you are into design patterns, it is worth noting that the DBI implementation is a simplified version of the Bridge Pattern (simplified in that we don't normally subclass any of the DBI classes). It also bears a strong resemblance to the Strategy Pattern. I hope this helps explain some of the rational behind the DBI implementation. -- -- Jim Weirich / Compuware -- FWP Capture Services -- Phone: 859-386-8855