Managing DBContext state behind a data provider interface

Question

I have an interface IDataProvider which exposes (for sake of discussion) just 3 operations:

public interface IDataProvider
{
    // get a list of projects (just metadata)
    List<Project> ListProjects();

    // load the Project by its GUID which we got from the metadata.
    Project LoadProject(Guid id);

    // save the project. underlying provider should determine to insert or update accordingly.
    void SaveProject(Project data);
}

I am using DBContext accessing an SQL CE as the under lying data access layer data provider and I could implement:

public DataProvider : SqlCeDbContext, IDataProvider { ... }

or

public DataProvider : IDataProvider
{
    List<Project> ListProjects()
    {
        using(var ctx = new SqlCeContext())
        {
            //... manage the life of the context for the API user.
        }
    }
    // ...
}

or

public DataProvider : IDataProvider
{
     SqlCeContext _mSqlCeContext = new SqlCeContext();

     List<Project> ListProjects() { .. }
     // ...
}

The three implementations will of course behave very differently with respect to connection and entity states. Since the interface "rules" does not enforce rules on this, which implementation is better? Or in case we should enforce one or the other, can it be done?

score 0 · Answer 1 · answered Dec 24 '11 at 19:02

Assuming that this is on a mobile device (which I believe is the case due to the SqlCE references), I think that you may be making your life slightly more complicated than needed.

There is no reason that you can't open a connection at application startup and leave it open through the life of the application since there shouldn't be any other applications using the database.

We've had production WinCE apps for years that use this approach and have never had an issue with it.

Managing DBContext state behind a data provider interface

1 Answers1