Question

所以在我的EF4项目中，我打开了DataContext文件本身的部分类，以及DataContext生成的一些Table / Object。但是，如果我打开一个“产品”类作为部分，那么就没有（据我所知）从产品备份到产生它的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参数传递给需要通过此连接访问数据库的任何部分类方法是否存在缺点？其中一个优点是一旦传入作为参考，我可以从这些部分类中“添加对象（）”新实体，并且一旦我在我的asp.cs页面上调用我的SaveChanges，所有的更改（来自aspx和部分类方法）得到执行。

Answer 1

首先，传递ref变量用于更改保存引用的变量。但是，由于您未在DataContext dbase方法中更改GetPByRole引用，因此将其作为ref传递是无用的，甚至会使其他开发人员感到困惑。也许您误解了值类型和引用类型。引用类型（例如DataContext）总是通过引用传递，通过方法调用传递它不会创建对象本身的新副本，而只是引用的副本（它是32位或64位值）。 / p>

其次，你在这里混合责任。您的Product类是一个实体，但您似乎在其上实现了所有类型的数据检索方法。这很快就会成为一大堆。为您的系统中的每个班级承担一项责任。 Person课程的责任是成为一个人。

换句话说，您尝试的更适合存储库类（甚至是服务类）。例如，创建一个包含这些方法的PersonRepository。 PersonRepository将能够返回新的Person实例（实际上，存储库应该只是数据源和应用程序之间的接口，并且通常不会实现与业务相关的查询方法）。这样，您就可以使您的实体免于了解数据上下文（这是ADO.NET团队在开发实体框架时非常慎重的设计决策）。

将DataContext对象作为'ref'参数传递的任何缺点？

1 个答案: