On 10/9/2011 2:22 PM, Andrei Alexandrescu wrote:
On 10/9/11 11:54 AM, Adam Ruppe wrote:
The way I'd do it is:
interface Database {
// support shared functions here, and other stuff useful enough to
// warrant emulation
}
class Postgres : Database {
// implement the interface, of course, but also all other postgres
// specific stuff
}
When you go to use it, if you're happy with the basics, declare
Databases.
If you need something special, use Postgres objects.
Makes sense. JDBC does that, too.
Andrei
Maybe "Database" should be an abstract class rather than an interface?
That's how ADO.net does it:
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.aspx
This is architecturally a little "cleaner", because whatever Postgres
database class we have is a "database" class at heart, not a class that
implements a database interface.
Also, perhaps some actual code that would exist in the abstract class
would be a call to Close() in the destructor. That way you can declare a
database connection on the stack, open it, do some stuff, allow it to
leave scope, and clean up that resource without a timeout on the server end.
