MVVM - one large repository vs many logical repository objects

Question

I asked this before but I wanted to ask again about the idea of creating one large repository vs many simple repository objects.

Using Northwind as an example, you could create a separate repository for each logical entity. This might give you a ObjectContext for each entity that is then referenced by something like this:

• CustomerRepository
• EmployeeRepository
• OrderRepository
• OrderDetailRepository
• ProductRepository
• CategoryRepsoitory

An alternative would be to have one massive or application wide NorthwindRepository which might reference a single ObjectContext that has all the entity references inside of it like this:

Public Class NorthwindContext
    Inherits ObjectContext
    Public Property Categories As ObjectSet(Of Category)
    Public Property Products() As ObjectSet(Of Product)
    Public Property Customers() As ObjectSet(Of Customer)
    Public Property Orders As ObjectSet(Of Order)
    Public Property Order_Details As ObjectSet(Of Order_Detail)
    Public Sub New()
        MyBase.New("name=NorthwindEntities", "NorthwindEntities")
        Categories = CreateObjectSet(Of Category)()
        Products = CreateObjectSet(Of Product)()
        Customers = CreateObjectSet(Of Customer)()
        Orders = CreateObjectSet(Of Order)()
        Order_Details = CreateObjectSet(Of Order_Detail)()
    End Sub
End Class

My original thought was it would be best for performance to logically separate out all the Repository objects. However when looking back at the Josh Smith article I realized that having one central repository for all CRUD would have one large benefit in an MVVM pattern. All events could be centrally located for all the entities.

If a Northwind "corporate" wide application were written it might need to reference all the entities. Picture one large screen with a list of Orders, Customers, Products, and Employees for example. If each list were to allow CRUD then it would affect all the other lists. If each entity had it's own view model then communication between these separate view models could come in handy. For example, removing an item from the Order_Detail updates the list of Products that are part of the Order. If one massive Repository were used for the CRUD on all the separate entities then each view model would be sharing that same Repository object and thus could subscribe to various events raised like Order_Detail_Deleted if they needed to.

Since the scenario just listed is typical it makes me think that best practice might be to create application wide Repository objects that include CRUD for all the entities used. This would not promote re-use later though. For example, if HR wanted a small application to just manage Employees then using the Northwind Repository object would be overkill. But it would lend itself to having events in a central location making it easy to communicate between various entity collections that are probably in their own view models.

Is it common to create application wide Repository objects that handle CRUD for all the entities used by an application? Or is the better practice to logically separate out the Repository objects? If you find it better to separate it out, then I'd like to hear at a high level how you handle event communication.

Answer 1

Intersting that you ask about repositories.  I've been trying to understand how they fit in with EntityFramework for a while now...  I don't see any advantage to them when using EF.  Why because EF maps the context into class which ARE in memory.  In addition, they support partial classes so that the Business logic can be built into the EF layer.  I'd say dig into EF and see if it solves your concern.

---

JP Cowboy Coders Unite!

Answer 2

I'm not sure I want to embed my business logic into the EF layer. But I have read a few threads on how a repository and unit of work approach is a wasted idea with EF since dbcontext and dbset offer the same functionality. However I have yet to find someone who can show exactly how this is done.

I am still trying to research the topic more. One concern I have is I am finding more about how dbcontext should not be persisted for long periods of time. All the examples I've found so far are not built around this idea. As near as I can tell the examples I've found do in fact persist the data for long periods of time. I am trying to research that more too which may be a separate topic.

Answer 3

I to have been researching this for about two weeks, there is a serious lack of any examples regarding the "Best Practice" usage of a DbContext in an MVVM application of any scale.  All the examples I've found have about 3 entities with 2 or 3 fields apiece, and they use one DbContext for the entire application.  

I'm currently working on a app that has a small to medium size model with about 8 entities, but the model could grow to as many as 20 entities as I figure things out...  I would love to move forward, and have a little, but I'm concerned about working myself into a corner...  Taking advantage of the Local property on each Entity-Collection by binding it to an observableCollection in a View-Model is great, but past that I'm not feeling lots of love...

I started with a auto generated DbContext from a Model First development.  Since then I've read that it's better to split up your DbContexts by logical function of what needs worked with together in the Db, but this certainly complicates things in my mind such as when you do that, what happens to navigation properties to things outside your current DbContext?  Have you settled on a path at this point and how is it working for you?

I have two SO questions regarding the general issue of MVVM with DbContext...  No answers yet.  

http://stackoverflow.com/questions/11819598/wpf-mvvm-entity-framework-using-ado-net-dbcontext-generator-best-way-to-get

http://stackoverflow.com/questions/11836005/mvvm-master-detail-views-with-ef-dbcontext-lazy-loading-multiple-viewmodels-o