Question

我正在使用Windows窗体构建一个小型数据密集型应用程序。在主项目中，我有一个文件夹，用于保存我的DBML以及数据类，以便为数据库提供CRUD操作。目前大约有10个数据类。

表单中的代码实例化业务对象，并对它们进行调用以完成所有工作。这些业务对象正在对静态数据访问类进行调用。

数据类的一个例子就是这样的

static class CustomerData
{
    public static IEnumerable<Customer> GetCustomersForRun(int runID)
    { 
         var db = new FooDataContext("connectionString");
         return db.Customers.Where(ri => ri.RunID == runID);
    }
}

现在很明显我的初始设计存在一些问题需要解决。

1）让每个静态方法都需要创建自己的DataContext并不好。这根本不是很干。

2）因为我依赖于一些延迟加载，所以我无法将我的DataContext包装在using语句中。

我必须解决这个问题的几个不同的想法是

1）摆脱静态方法，改为创建一个可以实例化我的DataContext的抽象基础数据访问类。

2）让每个业务对象创建自己的DataContext并将其传递给数据访问类的静态方法。

方法签名的一个例子是

public static IEnumerable<Customer> GetCustomerForRun(DataContext db, int runID)

我的具体问题是

1）我过度复杂吗？

2）您通常会丢弃DataContext对象吗？

3）我的哪个解决方案最有意义？如果他们都没有你推荐什么？

Answer 1

1）我过度复杂吗？

这实际上取决于你的应用程序是否非常小，混合使用的模式可能会使事情变得更复杂，只需使用DataContext可能会使事情更容易理解而不是在linq之上添加一层抽象SQL。

2）您通常会丢弃DataContext对象吗？

这将取决于你的植入，如果你打算通过一个IQueryable<T>进行过滤包裹using(){}块将导致你的悲伤。由于linq to sql仅在您执行调用GetEnumerator()的操作时触发sql查询，因此您的上下文可能会被处理，并且您的调用将失败。

Conceder这个例子：

IQueryable<Table> GetStuff()
{
  using(var db = new DataContext())
  {
     return db.Tables.Where(i=>i.Id == 1);
  }
}

如果在另一种方法中尝试执行此操作GetStuff().Where(i=> i.Name == "Jon").ToList()将导致查询失败，因为已经处理了上下文。

现在，如果你不这样做，你可以获得IQueryable

的力量

IQueryable<Table> GetStuff()
{
  return db.Tables.Where(i=>i.Id == 1);
}

GetStuff().Where(i=> i.Name == "Jon").ToList()将起作用并允许您过滤掉查询并将sql语句的执行推迟到最后一分钟。可以找到更多信息here。

3）我的哪个解决方案最有意义？如果他们都没有你推荐什么？

我经常试图远离静态类/方法，因为它使单元测试变得非常困难。可能有一些好的信息是查看Repository pattern和answer，它会提供一些快速信息。

Datacontext和数据访问类设计的改进

1 个答案: