Question

I’m trying to get started with the repository pattern and ASP.NET MVC, and I can’t help but believe I’m missing something. Forgive me if this is a stupid question, but it seems to me like an implementation violates DRY exponentially. For example, in my (admittedly novice) understanding in order to implement this, I would have to:

1. Create my database model (Currently using Linq to Sql)
2. Create a IRepository for each concept (table or group of related tables)
3. Create an implementation for each IRepository
4. Do we return L2S objects or some sort of DTO?
5. Create viewmodels which either are containers or copies of the data
6. Use some method of DI (Windsor or Unity?) on the controllers

While I realize scalability and portability come at an expense, it just feels like I’m missing something?

Answer 1

I tried to implement the Repository Pattern in LINQ 2 SQL and it doesn’t work very well, mainly because L2S doesn’t use POCOs and you have to map to DTOs all the time as you mention. Although you could use something like AutoMapper, L2S just isn’t a very good fit for the Repository Pattern.

If you’re going to use the Repository Pattern (and I would recommend it), try a different data access technology such as NHibernate or Entity Framework 4.0’s POCO support.

Also you wouldn’t create a Repository for each and every table, you create a Repository per Domain Aggregate, and use the Repository to access the Aggregate’s Root entity only. For instance, if you have an e-commerce app, with Order and OrderItem entities, an Order has one-or-many OrderItems. These 2 entities are part of a single Aggregate, and the Order entity is the Aggregate Root. You’d only create an OrderRepository in this case, NOT an OrderItemRepository as well. If you want to add new OrderItems you’d do so by getting a reference to the Order entity, then adding the new OrderItem to the Order’s Items collection, then saving the Order using your OrderRepository. This technique is called Domain Driven Design, and it’s a very powerful paradigm to use if you have a complex Domain Model and business rules in your application. But it can be over kill in simple applications, so you have to ask yourself does the complexity of your Domain Model warrant using this approach.

In terms is adhering to DRY, normally I create a base Repository class that has common methods for Save, Delete, FetchById, that sort of thing. As long as my Repository classes implement this base class (OrderRepository, ProductRepository etc.) then they get these methods for free and the code is DRY. This was easy to do in NHibernate because of POCO support, but impossible to do in Linq 2 SQL.

Don’t worry too much about sending your Domain Models directly to the view, most dedicated ViewModels look almost identical to the Domain Model anyway, so what’s the point. Although I tend to avoid using the DM for posting data back to the server because of under/overposting security concerns.

If you follow this POCO approach (and ditch LINQ 2 SQL, honestly!!), you end up with only one class (your POCO entity) instead of 3 (L2S class, DTO and ViewModel).

It is possible to implement the Repository Pattern badly, so tread carefully, read a few tutorials, blog posts books etc. (I recommend Steven Sanderson’s book, especially look at the Pre-Requisites chapter) But once mastered, it becomes a very powerful way to organise the complexity of hydrating Model objects to and from a data-store. And if you use Repository interfaces (IOrderRepository etc.) and have them injected via an IOC Container, you also gain the benefits of maintainability and unit testability.