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

【问题标题】：Should DB layer members be static or instance?DB层成员应该是静态的还是实例的？
【发布时间】：2010-09-06 04:37:29
【问题描述】：

我见过一些项目，其中 DB 层中的类只有静态函数，而其他项目需要实例化这些类才能访问成员函数。

哪个“更好”，为什么？

【问题讨论】：

【解决方案1】：

我喜欢将单个对象与数据库中的单个记录相关联，即必须实例化一个对象。这是您的基本ActiveRecord 模式。以我的经验，一个对象到一个行的方法在代码中创建了一个更加流畅和有文化的表示。另外，我喜欢将对象视为记录，将类视为表。例如要更改我所做的记录名称：

objPerson = new Person(id)

objPerson.name = "George"

objPerson.save()

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

aryPeople = Person::getPeopleFromState("LA")

有很多对 Active Record 的批评。当您为每条记录查询数据库或您的类与数据库紧密耦合时，您尤其会遇到问题，从而在两者中造成不灵活。在这种情况下，您可以提升一个级别并使用DataMapper 之类的内容。

许多现代框架和ORM's 都意识到了其中的一些缺点并为它们提供了解决方案。做一些研究，你会开始发现这是一个有很多解决方案的问题，这一切都取决于你的需求。

【讨论】：

【解决方案2】：

这都是关于数据库层的目的。如果您使用实例访问 DB 层，则您允许该类的多个版本存在。例如，如果您想使用相同的 DB 层来访问多个数据库，这是可取的。

所以你可能会有这样的事情：

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

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

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

【讨论】：

【解决方案3】：

正如 lomaxx 所提到的，这完全与 DB 模型的目的有关。

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

【讨论】：

【解决方案4】：

我会说这取决于您希望“数据库层”做什么......

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

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

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

【讨论】：

【解决方案5】：

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

【讨论】：

【解决方案6】：

这取决于您订阅的型号。 ORM（对象关系模型）或接口模型。由于 nhibernate、LINQ to SQL、Entity Framework 等框架，ORM 现在非常流行。 ORM 允许您围绕对象模型自定义一些业务约束并传递它，而实际上并不知道它应该如何提交给数据库。与插入、更新和删除相关的一切都发生在对象中，开发者不必太担心。

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

我会说使用 ORM。

【讨论】：