none
Repository/dbContext design - multiple vs single RRS feed

  • Question

  • Using Northwind as an example, I am wondering would it be better to create a single large Repository and dbContext module for all possible needs or break it down into multiple repository objects for specific needs (Product, Order, Customer ...).

    Single NorthwindRepository

    • + All data needs in one module
    • + All view models can refer to same module
    • + Change in data layer confined to one spot
    • - Individual or smaller support apps (Product maintenance) would have access to extra data

    Mulitple dbContext / Repository

    • + Each business unit could control their own data layer (Order, Product, Customer)
    • + Individual or smaller support apps limited to their own data
    • - Global corporate app (Northwind) needs to reference multiple sources (Order, Product, Customer)
    • - Maintenance of multiple data modules

    If you were to develop a Northwind application it seems wasetful to create a separate Repository for each entity (Order, Product, Employee) when you know that at any given time you will probably need all that information. On the other hand it also seems wasteful to bundle all that data logic in one area when you might not always need it. For example, if you were to create a small separate application for the product group so they could manage their products. In that case, it would be a waste to include functionality related to employee information.

    All this is basic stuff. Just wondering if there are other considerations that might come from having more experience with this.

    Thursday, May 24, 2012 7:09 PM

Answers

  • Hi pretzelb,

    I don't think is a good idea to have a single repository, usually with EF i create one Context and one repository for each Entity, my repository simply implement a generic repository<TEntity> and no other code is present; I implement services, which relies on repository for accessing data, where my business logic resides.

    If you have to work with a large, very large dB a single context can become too slow so you can split down your context into smaller pieces for improve the performance (e.g. context creation time).

    Hope it helps.

    Thursday, May 24, 2012 9:22 PM

All replies

  • Hi pretzelb,

    I don't think is a good idea to have a single repository, usually with EF i create one Context and one repository for each Entity, my repository simply implement a generic repository<TEntity> and no other code is present; I implement services, which relies on repository for accessing data, where my business logic resides.

    If you have to work with a large, very large dB a single context can become too slow so you can split down your context into smaller pieces for improve the performance (e.g. context creation time).

    Hope it helps.

    Thursday, May 24, 2012 9:22 PM
  • I can see your point but it does seem wasteful to create multiple context and repository modules when your final goal is a single application that will use them all.
    Friday, May 25, 2012 3:27 PM