.net - 将 DataContext 对象作为 'ref' 参数传递有什么缺点吗？

Question

因此，在我的 EF4 项目中，我打开了 DataContext 文件本身的部分类，以及 DataContext 生成的几个表/对象。但是，如果我将“产品”类作为部分打开，则(据我所知)没有从产品备份到产生它的 DataContext 类的直接链接。

public partial class Product 
{
    public DataContext GetContext() 
    {
        return this.DataContext; 
        // FAILS!!! No connection from 'this' to DataContext
        // makes sense because "Product" isn't REALLY derived from DataContext
        //...but still, I want this to work!
    }
}

但是在部分产品类中，我确实希望能够直接查询数据库，并且我真的希望能够只初始化一个 DataContext 实例并将其用于我的 aspx.cs 页面查询以及执行的查询来自从 aspx.cs 页面调用的部分类。

因此，到目前为止，我的解决方案是将 DataContext 的实例作为“ref”参数传递给需要遍历数据库的部分类的方法。这是部分类:

public partial class Complaint
{
    public IEnumerable<Person> GetPByRole(InvestigationRole roleEnum, ref DataContext dbase)
    {
        var role = dbase.GetRole(roleEnum);
        return this.PeopleOnInvestigations
                   .Where(x => x.InvestigationRoleID == 1)
                   .Select(x => x.Person);
     }
}

那么将我的 DataContext 对象作为 ref 参数传递给需要通过此连接访问数据库的任何部分类方法是否有缺点？ 好处之一是，一旦它作为 ref 传入，我可以从这些部分类中“AddObject()”新实体，一旦我的 SaveChanges 在我的 asp.cs 页面上回调，所有更改(从 aspx 和部分类方法)得到执行。

Answer 1

通过 ref变量用于能够更改保存引用的变量。但是由于您没有更改 DataContext dbase引用您的GetPByRole方法，将其作为 ref 传递是无用的，只会让其他开发人员感到困惑。也许你误解了值类型和引用类型。引用类型(例如 DataContext )总是通过引用传递，通过方法调用传递它不会生成对象本身的新副本，只会复制引用(它是 32 位或 64 位值)。

你在这里混合责任。您的 Product class 是一个实体，但您似乎正在其上实现各种数据检索方法。这很快就会变成一团糟。给系统中的每个类一个单一的职责。 Person 的责任类是一个人。

换句话说，您尝试做的更适合存储库类(甚至是围绕它的服务类)。例如，创建一个 PersonRepository持有这些方法。 PersonRepository将能够返回新的Person实例(事实上，存储库应该只是数据源和应用程序之间的接口(interface)，通常不会实现与业务相关的查询方法)。通过这种方式，您可以让您的实体无需了解数据上下文(这是 ADO.NET 团队在开发 Entity Framework 时非常慎重的设计决定)。