 |
 |
Casey Durfee wrote: > >I thought that was the point of using interfaces? I guess I don't get why you need a standard to be compelled to do something you should be doing anyway -- coding to interfaces, not implementations. > > Interfaces work well with like products (a database abstraction library is a great example), however interfaces don't lend well to products that achieve a similar goal but work differently altogether. Relational databases all work the same: there are databases, each database has tables, views, procedures, etc. and each table has columns, etc. However more infantile systems such as xml storage systems are hard to map in a similar fashion. I ran into this exact problem, I developed a system around eXist and developed an interface for the data layer and a "driver" for interacting with exist. I then wanted to compare other databases such as berkeley db xml. I quickly found that they achieve a common goal, but do not implement the same concepts making them very hard to compare. eXist has "collections" to group your xml into distinct groupings and db xml does not. In my interface I had a method called getCollections, but since db xml does not have anything like this, I could not use that method. So now how would you develop an interface that would include various xml databases as well as full-text index systems such as lucene, etc. I would image this would be very challenging.