高分请教有关ADO编程实际问题.(请各位高手进来坐坐)
我刚刚用VC来开发有关数据库程序不久，在开发过程有一问题，特来请教各位高手一下：
在实际开发一个数据库项目（使用VC6+ADO+SQL Server）中，是否自己再封装一下ADO对象比较好呢？我看了有些例子，比如有一数据库操作类大致是这样的形式的
class CBaseData
{
public:
CBaseData();
~CBaseData();
//连接数据库
void ConnectDB();
//对数据库进行操作
void ExecSQL(CString strSQL);
//关闭连接
void CloseDB();
private:
_ConnectionPtr m_pCon;
_CommandPtr m_pCom;
_RecordsetPtr m_pRst;

};
具体的实现大致就是在这个类的构造函数 都先对生成连接对象并对数据库进行连接，在析构函数中进行 关闭连接，并删除m_pCon变量。

在实际使用这个类都用
CBaseData db=new CBaseData();
db.ExecSQL(strSQL);
db.CloseDB();
delete db;
这样的方式去使用。个人觉得这种方式 每一次操作数据库都要 先去连接一下数据库，这样的话是否会造成一些性能的损失呢？有没有什么个更好的方法?各位实际开发的项目大致是 怎么去操作数据库的呢？

[解决办法]
如果业务简单，数据关系也简单，推荐直接使用ADO，不要再进行封装
业务简单，数据关系复杂，不要封装
业务复杂，数据关系简单，可以封装
业务复杂，数据关系复杂，不要封装

从性能考虑，如果业务复杂，就看你偏重哪一方面。



[解决办法]
不封装。

每一次操作数据库都要 先去连接一下数据库，这样的话是否会造成一些性能的损失呢？
你封装了还不是一样。
[解决办法]
每次都去连接显然受不了.
[解决办法]
将 _ConnectionPtr m_pCon;申请为成员变量，初始化时连接一次，以后多次使用，析构时关闭连接。这其中你非常需要 _ConnectionPtr 的一个成功State，因为它表达了当前连接的状态，比如是否可用。
[解决办法]
connection对象的stat并不能真正的反映与数据服务器的连接是否正常，尤其是远程数据库的物理连接中断，connection的stat是无法真正的体现的

封装之后，通常会对外公布一个成员来表示当前数据库是否连接，通常都是返回state,如上所述，这个成员无法处理物理连接不可靠的情况下的真实情况，所以大多数封装的类对于程序的稳定性无法提供更好的帮助，最好是自己采取链接检查机制。所以不封装为好

至于是否每一次DB操作都需要去链接，对于大数据频繁的操作肯定不可取，至于何时去链接，第一要设计物理链路检测和数据库服务是否启动检测，要定时轮询，结合state来确定connection是否可以用，是否重新链接还是释放当前connection，从新实例化新对象来链接
[解决办法]
对于state的判断，如果为0，则肯定是关闭的，如果为1，则也可能是关闭的，相比不判断要好。至少它可以准确的判断连接是关闭的！！

我的做法是，在state为1时，就进行数据库操作，同时catch错误，如果出错（当然，SQL语法的错误要排除），就关闭连接，这样，下次再次运行到这段程序的时候，通过state的判断，就是准确的了！