在Web应用程序中选择静态和实例数据访问类的优缺点是什么？

Question

我已经阅读了关于这个主题的其他几个问题（ 这里 ， 这里 ， 这里 ），但还没有看到一个很好的答案。 我之前已经开发了我公平的数据访问层，并且个人更喜欢使用实例类而不是静态类。 但是，它更多的是个人偏好（我喜欢测试我的业务对象，这种方法可以更容易地模拟DAL）。 我之前使用静态类来访问数据库，但我总是觉得这种设计的适当性有点不安全（特别是在ASP.NET环境中）。

任何人都可以在这两种方法中使用ADO.NET提供程序（无ORM）开发数据访问类，特别是在ASP.NET应用程序中，可以提供一些好的优点/缺点。 如果您有更一般的静态与实例类技巧，请随意加入。

特别是，我担心的问题是：

1. 线程和并发
2. 可扩展性
3. 性能
4. 任何其他未知数

谢谢！

Answer 1

基于静态的方法通常只有一个，而且只有一个主要优点：它们易于实现。

基于实例的方法赢得了：

1. 线程和并发 - 您不需要任何/同步，因此您可以获得更好的吞吐量
2. 可伸缩性 - 与上述问题相同
3. 逆足 - 与上述问题相同
4. 可测试性 - 这更容易测试，因为模拟实例很容易，测试静态类很麻烦

静态方法可以赢得：

1. 内存 - 您只有一个实例，因此占用空间较小
2. 一致性/共享 - 保持单个实例与自身一致很容易。

总的来说，我觉得基于实例的方法更优越。 如果您要扩展到单个服务器之外，这一点变得更加重要，因为一旦您开始在多台计算机上实例化，静态方法就会“中断”...

Answer 2

我的一般感觉是：为什么要实例化，如果你没有？

当不能用于多个实例并且不需要实例成员时，我使用静态类。 至于DAL，重点是只有一个。 如果它没有价值，为什么要实例化呢？

看看这个链接 ，它表明静态方法调用比实例类方法调用更快。

此链接显示使用静态类的一个优点是编译器可以检查以确保不会意外添加实例成员。

此链接显示静态类可以用作方便的容器集合，这些方法只对输入参数进行操作，而不必获取或设置任何内部实例字段。 对于DAL，这正是您所拥有的。 没有理由创建任何内部实例字段，因此没有理由进行实例化。

Answer 3

我多年来一直在使用静态DAL，我同意你的担忧。 线程和并发是最具挑战性的，在我的情况下，我将不同的连接对象存储在线程静态结构中。 它已被证明是非常可扩展的并且表现良好，现在我将PropertyInfo转换为PropertyDescriptor，这给了我更好的性能反射的相同好处。 在我的DAL中，我只需写：

 List<Entity> tableRows = SQL.Read(new SearchCriteria(), new Table());

所有东西都会产生SQL静态类，这使我的代码变得更加简单。

Answer 4

对我来说，主要原因是我不需要保持该DAL对象的状态。 它使用的对象的状态不会跨越它们嵌入的方法的范围。 这样，为什么你会保留一个对象的多个实例，如果它们都是相同的？

使用最新版本的ADO.NET，似乎是在调用范围内创建和销毁数据库连接的最佳实践，并且让ConnectionPool无论如何都要处理整个连接的可重用性问题。

再次使用最新版本的.NET Framework，TransactionScope（这将是您自己管理连接的一个原因）向上移动到业务级别，这允许您在同一范围内连接多个DAL调用。

因此，我无法看到创建和销毁（或缓存）DAL实例的强制案例。