当数据使用者激增时，我如何保持干燥和凝聚力

本文关键字：何保持 凝聚力 使用者 数据 | 更新日期: 2023-09-27 18:37:27

我有一个静态类，我将其用作项目的"数据实用程序"。

此项目具有多个窗体和类

，其中多个窗体和类调用此 Data Utils 类/数据库。

我不想违反 DRY 原则，所以我不想有多个 OracleConnection 组件，每个表单上都有一个组件。

我也不想通过让我的 Data Utils 类获得我的主要窗体的"肉体"知识并为 OracleConnection 访问它来破坏凝聚力。

我可以在每个Data Utils方法中创建一个动态的OracleConnection，但这也会违反DRY。

我的最佳解决方案是将静态类转换为非静态类，为其提供 OracleConnection 成员，并在构造函数中实例化它？

更新

对于后代，这就是我根据LukLed的建议所做的：

internal class GreatAmericanNovelistsData
{
    private static OracleConnection oc;
    static GreatAmericanNovelistsData()
    {
        oc = new OracleConnection();
        oc.ConnectionString = "User Id=SCLEMENS;Password=HucKfiNn;Server=HANNIBAL;Pooling=True;Min Pool Size=0;Max Pool Size=10;Connection Lifetime=0;Direct=True;Sid=HANNIBAL;Service Name=HANNIBAL;";
        oc.Direct = true;
    }

当数据使用者激增时，我如何保持干燥和凝聚力

只能定义静态构造函数并初始化连接一次。 OracleConnection对象也可以是静态的。详情请见此处。

class SimpleClass
{
    // Static constructor
    static SimpleClass()
    {
        //...
    }
}

是我将静态类转换为非静态类的最佳解决方案，给它 一个 OracleConnection 成员，并在构造函数中实例化它？

但这会违反依赖关系反转主体;)

这听起来有点类似于我在最近的应用程序中所拥有的，我最终做的是有一个返回我的 OracleConnection 实例的工厂（我有一个工厂，因为我需要确保每个线程 1 个实例，所以我在工厂中处理它）。工厂实现了一个接口，各种构造函数接受一个参数，即该接口。依赖注入框架（如 Unity 或 Ninject）用于注入适当的工厂。 这也使它更具可测试性，因为我可以模拟工厂。

所以在代码中，我最终做了类似的事情（如果语法稍微偏离，这很抱歉）：

public interface IDbConnectionFactory
{
  public IDbConnection GetConnection();
}
public class OracleConnectionFactory : IDbConnectionFactory
{
  public IDbConnection GetConnection()
  {
    return new OracleConnection();
  }
}
public class MyAwesomeDataAccess
{
  private IDbConnectionFactory dbConnectionFactory;
  public void MyAwesomeDataAccess(IDbConnectionFactory() dbConnectionFactory)
  {
    this.dbConnectionFactory = dbConnectionFactory;
  }
  public SomeData SomeMethod()
  {
    var connection = dbConnectionFactory.GetConnection();
    // do stuff with connection...
  }
}

然后在我的 Unity 配置中，我映射了IDbConnectionFactory -> OracleConnectionFactory

当然，这可能不是在所有情况下对每个人都最好的，但我只是想就一种可能性给出一个想法。希望你能找到一个适合你的好方法！

相关文章：