从应用程序中的任何位置访问数据库

在我看来,您需要创建一个适当的对象(包含连接或类似对象),并将该实例传递给 需要访问的每个对象 (见 dependency injection )

这与使用单件不同。通过使用这种机制,它将使您从对一个对象的依赖中解脱出来,并且(在本例中可能是一个更令人信服的原因)允许您通过注入模拟对象或类似对象来代替最初注入的数据库访问器对象来执行测试。在这种情况下,我肯定会避开单体机制。

我总是用 singleton pattern . 至于配置,请看 system.configuration.configurationmanager(系统配置管理器) 类,该类允许您从项目的app.config/web.config文件中读取设置。

在OOP中定义数据库访问的绝对最佳实践有点困难。

你的头脑中有很多因素需要考虑:

• 如何处理配置参数?
• 应用程序是多线程的吗?是否需要数据库连接池?
• 您是否需要数据库可移植性(即:在开发和生产中是否使用不同的DBS)?您是否担心供应商锁定一个数据库?您是否在向其他可能使用不同数据库的用户分发应用程序?)
• 您关心的是保护SQL语句的安全,还是集中实施其他访问权限?
• 在执行某些插入和更新时,是否涉及到常见的逻辑,而您不愿意在触摸到特定表的任何地方复制这些逻辑?

正因为如此,许多OOP人员将注意力集中到ORM框架中,而不是最简单的情况。一般的想法是,应用程序逻辑不需要在任何时候直接与数据库通信:尽可能长时间地将业务代码与实际的持久性机制隔离开来。

相反,尝试设计应用程序,以便业务逻辑与模型层对话。换句话说,在系统中具有封装和描述业务数据的模型对象。然后,这些模型对象公开了获取并将其状态保存到数据库中的方法,但您的逻辑不需要关心这一点。

例如,假设您的系统中有一个称为“人”的概念。您可能会将此建模为具有一些属性的类。在伪代码中:

Person:
    - first_name
    - last_name

然后,系统中的实际代码只与实例化和使用Person对象有关,而与获取DB句柄或编写SQL无关:

p = Person.get(first_name='Joe')
p.last_name = 'Bloggs'
p.save()

在面向对象的世界中,您会发现您的业务逻辑代码变得更干净(更短!)更容易维护,更容易测试。

当然,你是对的,这意味着你现在需要开始构建一个数据库后端来转换它。 Person 类到关系数据库中的一个或多个表。这是使用 ORM 框架很有用。在python中,人们使用django和sqlacalchemy。我会让其他人指出人们在C(我不是C开发人员,但你确实标记了你的问题) OOP ,所以我在这里选择通用答案,而不是特定于C)。

不过,关键在于,ORM框架将所有的DB访问放在代码中的一组类中,以便在一个地方处理DB访问、配置和池…不需要在整个应用程序中实例化它们。在“需要的地方”使用的是模型对象。

当然,如果你的应用程序非常简单,你只需要一个原始的DB句柄,那么我推荐其他人列出的依赖注入方法。

希望有帮助。

实际上,我使用一个存储库类,它在其构造函数中接收数据库信息,并将需要它的类传递给它。实际上,我使用控制反转(IOC)工具将这些值注入。

您可以将用户信息存储在平面文件中的某个地方,然后从DB类对其进行读/写操作。

这样您就不会复制代码中的设置,但用户仍然可以修改这些设置。

SubSonic 是用于对象关系映射的“瑞士军刀”,并提供执行存储过程和将结果返回到列表的能力。你可以在半小时内启动和运行它。