Database DB层成员应该是静态的还是实例的？

我见过DB层中的类只包含静态函数的项目，以及需要实例化这些类以访问成员函数的其他项目

哪一个更好？为什么

---

这都是关于DB层的用途。 如果使用实例访问DB层，则允许该类存在多个版本。例如，如果希望使用同一个DB层访问多个数据库，这是可取的

所以你可能会有这样的想法：

DbController acrhive = new DbController("dev");
DbController prod = new DbController("prod");

它允许您使用同一类的多个实例访问不同的数据库

---

相反，您可能希望一次只允许在应用程序中使用一个数据库。如果您想这样做，那么您可以考虑为此使用静态类。

这取决于您订阅的模型。ORM（对象关系模型）或接口模型。ORM现在非常流行，因为有nhibernate、LINQ到SQL、实体框架等框架。ORM允许您自定义对象模型周围的一些业务约束，并传递这些约束，而实际上不知道如何将其提交到数据库。与插入、更新和删除相关的一切都发生在对象中，开发人员不必太担心

像微软流行的企业数据模式这样的接口模型要求您知道对象处于什么状态以及应该如何处理它。它还要求您创建必要的SQL来执行操作

---

我想说使用ORM。

我希望单个对象与数据库中的单个记录相关联，即必须实例化一个对象。这是你的基本模式。根据我的经验，一个对象到一行的方法在代码中创建了一个更流畅、更具可读性的表示。此外，我喜欢将对象视为记录，将类视为表。例如，要更改记录的名称，请执行以下操作：

objPerson = new Person(id)

objPerson.name = "George"

objPerson.save()

为了让所有住在路易斯安那州的人都来，我可能会这么做

aryPeople = Person::getPeopleFromState("LA")

对现行记录有很多批评。特别是在查询数据库中的每条记录或类与数据库紧密耦合的情况下，您可能会遇到问题，这两种情况都会造成不灵活。在这种情况下，您可以向上移动一个级别，然后执行类似的操作

---

许多现代框架都意识到了其中的一些缺点，并为它们提供了解决方案。做一点调查，你就会发现这是一个有很多解决方案的问题，这都取决于你的需要

正如lomaxx所提到的，这一切都与DB模型的用途有关

---

我发现最好使用静态类，因为我通常只希望创建我的DAL类的一个实例。我宁愿使用静态方法，也不愿处理可能创建多个DAL类实例的开销，这些实例中只有1个应该存在，并且可以多次查询。

我想说，这取决于您希望“DB层”做什么

如果您有用于执行返回数据集的存储过程或sql语句的常规例程，那么使用静态方法对我来说更有意义，因为您不需要对为您创建数据集的对象的永久引用

如果我创建了一个返回强类型类或集合作为结果的DB层，我也会使用静态方法

另一方面，如果您想创建一个类的实例，使用一个给定的参数，比如ID（参见@barret conrad的答案），来连接到DB并获取必要的记录，那么您可能不想在该类上使用静态方法。但即便如此，我还是要说，您可能有某种DB Helper类，它确实有其他类所依赖的静态方法。

另一个“视情况而定”。然而，我也可以想到一个非常常见的场景，其中static不起作用。如果您有一个获得相当数量流量的网站，并且您有一个带有共享连接的静态数据库层，那么您可能会遇到麻烦。在ASP.Net中，默认情况下会创建一个应用程序实例，因此，如果您有一个静态数据库层，那么对于使用您的网站的每个人，您可能只能获得一个到数据库的连接