CODEWITHSUNDEEP
.netentity-frameworkwcfdbcontext
Hélder Gonçalves
Hélder Gonçalves

Reputation: 3942

Handle DBContext in WCF Service Library

I need to process a huge amount of data (CRUD in 500K+ records) in a click of a button in a ASP.NET website :) I thought about doing that using a WCF Service Library with Entity Framework 6. There's only one edmx so only one "context" I guess.

This is my DAL atm:

public interface IBaseRepository<T> : IDisposable
{
    void Insert(T entity);
    void BulkInsert(IEnumerable<T> entities);
    void Delete(T entity);
    IQueryable<T> GetAll();
}

public class BaseRepository<T> : IBaseRepository<T> where T : class
{
    protected DbContext _context;
    public BaseRepository(DbContext dataContext)
    {
        _context = dataContext;
    }
    public BaseRepository()
    {
        _context = new MyDBContext();
    }
    public void Insert(T entity){/*CODE*/}
    public void Delete(T entity){/*CODE*/}
    public IQueryable<T> GetAll(){/*CODE*/}
    public void Dispose(){ this.Dispose(); }
}

public interface IProductRepository
{
    IQueryable<Product> GetAllProducts();
}

public class ProductRepository : BaseRepository<Product>, IProductRepository
{
    ProductRepository()
        : base()
    {}

    ProductRepository(DbContext dataContext)
        : base(dataContext)
    {}

    public IQueryable<Product> GetAllProducts()
    {
        return base.GetAll();
    }
}

This last code will be repeated for each entity (each one will have a repository).

I'm wondering where should I create the DBContext, should I hand it to the contructor in each repository or let the BaseRepository contructor do its thing? If I hand it to each repository does it mean that I have to create it in the BLL? I don't want that :\

EDIT:

I'm doing some research on the subject but I've never used dependency injection frameworks.. so I don't know how to start :\

I'm not sure I understood what @MattSanders meant. I get that I should use something like Unity for dependency injection for the upper layer (the Controller), but where should I create the DBContext? Should I use the repository's empty constructor (that means that I'll have a context for each repository) or should I just hand it over as a parameter to each constructor (that way I can use the same context in all repositories)?

Upvotes: 1

Views: 788

Answers (1)

Matt Sanders
Matt Sanders

Reputation: 983

If you have code that depends on a specific instance of a Typed Repository than it might be valuable to accept the dbContext in the constructor to pass down to the base class constructor for testability.

In the following example you would have the option to provide a mocked out repository if you just want to test the controller functionality (Fake context with Mocked out DbSets or in memory instance like that provided by Effort)

public class ProductController
{
    private readonly ProductRepository _productRepository;

    public ProductController (ProductRepository productRepository)
    {
        _productRepository = productRepository;
    }

    public void BuyProduct(int id)
    {
        // Example of something to do
    }
}

This is definately not the only answer, but I wanted to share the limitations I see with testability if the dependency of the dbContext is handled in the base classes constructor and not exposed.

Edit: Here is a link to effort mentioned above: https://effort.codeplex.com/wikipage?title=Create%20a%20fake%20DbContext%20instance

Edit:

If I hand it to each repository does it mean that I have to create it in the BLL?

I have been using a factory with an IoC container to retrieve my repository instances and all of their dependencies, if you are not using a DI framework it can help with these types of scenarios.

Upvotes: 2

Related Questions