This is a continuation from another thread that got off-topic so I'd like to fire it up in here:

Originally posted by shunt

It is pointless trying to encapsulate ADO. Ask yourself: Why do I want to encapsulate ADO?
Actually tell me why you want to encapsulate ADO and I will convince you not to. ADO is the perfect adapter for database access... If anyone could make it any better, M$ would have payed them out ages ago. USE ADO, AS IS!
I agree, ADO follows its design pattern perfectly, but I disagree that the design pattern is complete.

As an adapter, ADO hides complexities from the consumer in a good albeit general way. Since it cannot hide all the complexities of your database - the specific design of your database (table names, field names - blah blah blah), some complexity leaks back into the client application, making it unnecessarily messy. (Ever seen what 100 different configurable SELECT statements looks like?

This is why I would want to encapsulate the ADO object - to contain all that mess. I guess what my goal is - is to write applications that have access to databases, but do not ever have to write SQL statements of any kind. Instead I would want a binary object to act as another Adapter interface between my application and ADO.