Question

如果我想在Delphi中访问数据库，我可以将一个数据模块添加到项目中，从我的mainform配置它，然后在应用程序的任何地方访问它;引用将存储在全局变量中。

我知道在C＃和其他更现代的OO语言中，全局变量都不受欢迎。那么如何从我需要的地方访问我的数据库呢？我遇到的最大问题是配置：位置，用户，密码等在设计时是未知的。

我现在有一个db-class并在需要时创建一个新实例，但是我必须将这些设置存储在一些全局可访问的东西中，我只是简单地解决了这个问题。

什么是标准解决方案？

谢谢，问候，Miel。

Answer 1

我总是使用singleton pattern。至于配置，请查看 System.Configuration.ConfigurationManager 类，它允许您从项目的app.config / web.config文件中读取设置。

Answer 2

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

你的头上有很多因素需要考虑：

如何处理配置参数？
是多线程的应用程序？你需要数据库连接池吗？
您是否需要数据库可移植性（即：您在开发中使用不同的DB而不是生产吗？您是否担心供应商使用一个数据库锁定？您是否正在将应用程序分发给可能使用不同数据库的其他用户？）
您是在担心保护SQL语句还是集中执行其他访问权限？
在执行某些插入和更新时是否涉及到通用逻辑，在触及特定表的任何地方都不会重复？

正因为如此，许多OOP人都倾向于使用ORM框架，除了最简单的情况。一般的想法是，您的应用程序逻辑不需要在任何时候直接与数据库通信：尽可能将您的业务代码与实际的持久性机制隔离开来。

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

例如，假设您的系统中有一个名为“Person”的概念。您可能将其建模为具有某些属性的类。在伪代码中：

Person:
    - first_name
    - last_name

系统中的实际代码只涉及实例化和使用Person对象，而不是获取DB句柄或编写SQL：

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

在面向对象的世界中，您会发现您的业务逻辑代码变得更清晰（更短！），更易于维护，并且更易于测试。

当然，你是对的，这意味着你现在需要建立一个数据库后端，将Person类转换为关系数据库中的一个或多个表。这是使用ORM框架派上用场的地方。在Python中，人们使用Django和SQLAlchemy。我会让其他人说明人们在C＃中使用了什么（我不是C＃开发人员，但你确实标记了你的问题OOP，所以我在这里寻找通用答案，而不是C＃特定的。） / p>

关键是，ORM框架将所有数据库访问权限放在代码中的一组类中，以便在一个地方处理数据库访问，配置和池...无需实例化它们遍布整个申请。你在“你需要它的地方”使用的是模型对象。

当然，如果您的应用程序非常简单并且您只想要一个原始数据库句柄，那么我建议其他人列出的依赖注入方法。

希望有所帮助。

Answer 3

我实际上使用的是一个存储库类，它在其构造函数中接收db信息，并且需要它的类将它传入。我实际上使用控制反转（IOC）工具来注入这些值。

Answer 4

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

这与使用单身人士不同。通过使用这种机制，它将使您免于依赖于一个对象，并且（在这个实例中可能是一个更令人信服的理由）允许您通过注入模拟对象或类似对象来代替最初注入的数据库访问器对象来执行测试。在这种情况下，我肯定会回避单身机制。

Answer 5

您可以将用户信息存储在某个平面文件中，然后从db-class读取/写入

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

Answer 6

SubSonic是用于对象关系映射的“瑞士军刀”，并提供执行存储过程并将结果返回到List的能力。您可以在半小时内完成并运行。

应用程序中随处可访问数据库

6 个答案: