Any downsides to passing around a DataContext object as a 'ref' parameter?

Question

So in my EF4 project I have opened up the partial classes of both the DataContext file itself, as well as a couple of the Table/Object generated by the DataContext. However, if I open up a "Products" class as a partial, there isn't (as far as I can tell) a direct link from product back up to the DataContext class that spawned it.

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!
    }
}

But inside by partial product class, I sure would like to be able to query the database directly, and I really like to be able to initialize just one instance of DataContext and use it for my aspx.cs page queries, as well as queries executed from the partial classes that are called from the aspx.cs page.

So my solution so far is to pass in the instance of DataContext as a 'ref' parameter to the methods of my partial class that need to poke around the database. Here's the partial class:

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);
     }
}

So is there a downside to passing around my DataContext object as a ref parameter to any partial class methods that need access to the database through this connection? One of the upsides is that once its passed in as a ref, I can "AddObject()" new entities to it from within these partial classes, and once my SaveChanges call back on my asp.cs page is made, ALL the changes (from the aspx and from the partial class methods) get executed.

Answer 1

Passing a ref variable is used to be able to change variable that holds the reference. But since you are not changing the DataContext dbase reference in your GetPByRole method, passing it as a ref is useless and would only confuse other developers. Perhaps you misunderstand value types and reference types. Reference types (such as DataContext) are always passed by reference, passing it around through method calls will not make new copies of the object itself, merely copies of the reference (which is either a 32 or 64 bits value).

You are mixing responsibilities here. Your Product class is an entity, but you seem to be implementing all kind of data retrieval methods on it. This will become a big mess very soon. Give every class in your system a single responsibility. The responsibility of the Person class is to be a person.

In other words, what you are trying to to is much more suited for repository classes (or even service classes around that). For instance, create a PersonRepository that holds these methods. The PersonRepository will be able to return new Person instances (in fact a repository should just be the interface between your data source and your application and would normally not implement business related query methods). This way you keep your entities free from knowing the data context (which is a very deliberate design decision of the ADO.NET team while developing Entity Framework).