This place is about random happenings @ East.

ASP.NET MVC, LINQ and Repository Pattern

Posted: October 13th, 2008 | Author: julian | 12 Comments »

A few days ago I've finally decided to spend some time with Microsoft's new ASP.NET MVC framework. Like all MVC implementations, the ASP.NET MVC framework provides a structured model that enforces a clear separation of concerns within applications, and makes it easier to unit test your code.  It also helps provide more control over the URLs you publish in your applications, and can optionally provide more control over the HTML that is emitted from them. Here is a nice article on the history of MVC pattern.

ASP.NET MVC is in a pre-beta stage, but it is quite stable and there are even production sites running on it. For example, one of my recently favorites stackoverflow.com, a great resource of programming knowledge, is running on ASP.NET MVC. (it is amazing how programmers working on different technologies/stacks can behave together and share the knowledge.)

Update: ASP.NET MVC is now officially in Beta. As usual, to get all the details, check out the latest epic installment on ScottGu’s blog.

The other new technology I wanted to play with is LINQ. A fast description of LINQ from Wikipedia: "LINQ defines a set of query operators that can be used to query, project and filter data in arrays, enumerable classes, XML, relational database, and third party data sources. While it allows any data source to be queried, it requires that the data be encapsulated as objects. So, if the data source does not natively store data as objects, the data must be mapped to the object domain. Queries written using the query operators are executed either by the LINQ query processing engine or, via an extension mechanism, handed over to LINQ providers which either implement a separate query processing engine or translate to a different format to be executed on a separate data store (such as on a database server as SQL queries). The results of a query are returned as a collection of in-memory objects that can be enumerated."

And finally, after months working with some old, heavy "spaghetti-code" PHP applications (pre-version 5) I wanted to enforce a design pattern when designing my classes. Specifically, I've decided to implement the Repository Pattern.

The Repository Pattern is a very popular way to abstract a domain model from the underlying data mapping and data access by providing access to domain objects (business objects) via a collection interface. For example, the business objects can form collections under a single repository object such as:

  • Repository.Projects
  • Repository.Customers
  • Repository.Managers, etc.

So, let's go!

Note: all the code listings below are written in C#, but i'm pretty sure the programmers will get the idea :)

First, we need to created the ASP.NET MVC project in Visual Studio. VS automatically is creating the project structure, folders, etc. , plus a test project where we can store the unit tests.

ASP.NET MVC Application

For this sample I have a simple table called "Projects". You can see the structure of the table below:

To create the LINQ classes, we need to add a new "LINQ to SQL classes" item to the Model folder, and then simply drag the "Projects" table to the Object Relational Designer designer. Visual Studio will take care and generate the classes. Additionally, you can drag stored procedures (if any). Later, you can access the stored procedures as methods of the respective LINQ class.

LINQ to SQL class

Ok, we have the MVC project, a table and the LINQ classes already. We need to access the data and pass it the views. We can access the LINQ classes directly from our controllers. For example:

Controllers/HomeController.cs

The Index() action above uses a LINQ to SQL DataContext class to represent the database. The DataContext class was generated by the Visual Studio Object Relational Designer.

A LINQ query is performed against the DataContext to retrieve all of the projects from the Projects database table. The list of projects is assigned to a local variable named allProjects. Finally, the list of projects is passed to the view through view data.

Working directly with LINQ to SQL in a controller class is perfectly fine in terms of MVC. However, it can create problems when you need to build a more complex application. It makes it difficult to switch data access technologies in the future. For example, you might decide to switch from using LINQ to using the Entity Framework, or strongly typed datasets, or whatever you like as your data access technology. In that case, you would need to rewrite every controller that accesses the database within your application. In addition, using LINQ to SQL within a controller class makes it difficult to build unit tests for your application.

The Repository Pattern

In order to build an MVC application that is more adaptable to future change and that can be more easily tested, we can use the Repository pattern. When you use the Repository pattern, you create a separate repository class that contains all of your database access logic.

When we create the repository class, we create an interface that represents all of the methods used by the repository class. Within the controllers, we write our code against the interface instead of the repository. That way, we can implement the repository using different data access technologies in the future.

The interface below is named IProjectRepository and it represents a single method named ListAll().

Models/IProjectRepository.cs

And the repository class below implements the IProjectRepository interface. Notice that it contains a method named ListAll() that corresponds to the method required by the IProjectRepository interface. 

Models/ProjectRepository.cs

Finally, we need to change the HomeController class to use the repository instead of using LINQ to SQL classes directly.

Controllers/HomeController.cs

Notice that the HomeController class has two constructors. The first constructor (the parameterless one) is called when your application is running. This constructor creates an instance of the ProjectRepository class and passes it to the second constructor. The second constructor has a single parameter: an IProjectRepository parameter. This constructor simply assigns the value of the parameter to a class-level field named _repository. This is an implementation of a software design pattern called the Dependency Injection pattern. In particular, Constructor Dependency Injection.

Notice that all of the code in the HomeController class (with the exception of the first constructor) interacts with the IProjectRepository interface instead of the actual ProjectRepository class. The code interacts with an abstract interface instead of a concrete implementation of the interface.

If you want to modify the data access technology used by the application then you can simply implement the IProjectRepository interface with a class that uses the alternative database access technology. For example, you could create an MySqlProjectRepository class or an EntityFrameworkRepository class. Because the controller class is programmed against the interface, you can pass a new implementation of IProjectRepository to the controller class and the class would continue to work.

Furthermore, if you want to test the ProjectController class, then you can pass a fake project repository class to the HomeController. You can implement the IProjectRepository class with a class that does not actually access the database but contains all of the required methods of the IProjectRepository interface. That way, you can unit test the HomeController class without actually accessing a real database.

Nice and simple!

PS. Of course, you can implement as much repository methods as you need. For example (and to show some more LINQ magic) we can implement GetById() method in the ProjectRepository class as follows:

and access it in our controller with something like var myProject = _repository.GetById(5);

Share this post:
  • Facebook
  • email

12 Comments on “ASP.NET MVC, LINQ and Repository Pattern”

  1. 1 Using Web Metrics To Analyze the ‘ Palin Effect’ & 2008 … said at 23:38:52 on October 13th, 2008:

    [...] ASP.NET MVC, LINQ and Repository Pattern [...]

  2. 2 ASP.NET MVC Archived Buzz, Page 1 said at 13:54:47 on October 16th, 2008:

    [...] to Vote[Del.icio.us] East.fi ” Blog Archive ” ASP.NET MVC, LINQ and Repository Pattern (10/16/2008)Thursday, October 16, 2008 from mkelley33SoC or the layerer approach can be achieved via the [...]

  3. 3 Andrei Rinea said at 03:06:21 on October 23rd, 2008:

    There is something that I don’t understand in using LINQ to SQL in Repository pattern :

    Let’s say that I will create an assembly for each of the Repository providers (LINQ to SQL, MySQL, Oracle, WebService, XML files etc. etc.). I will define the IRepository interface in a common assembly (let’s call it ‘Interfaces’) that will be referenced by any Repository provider assembly. But where will the entity classes (‘Project’ in your example) be placed? Since they are generated by Visual Studio or by SQL Metal they would live in the LINQ to SQL provider but they are required in the ‘Interfaces’ assembly so I have a circular problem.

    How do I go about this?

  4. 4 julian said at 00:14:35 on October 25th, 2008:

    Hello Andrei,
    Interesting question! I don’t have any ready solutions in place. What I can think at the moment, you can add another layer, wrapping the LINK to SQL classes and passing serialized objects to the repository layer (i.e. Fowler’s “Data Transfer Objects”).

    I’ll try to come with something during the weekend.

  5. 5 jon said at 22:11:23 on January 9th, 2009:

    Great article! Any chance of showing how to create the unit tests with the fake repository?

  6. 6 julian said at 16:28:54 on January 10th, 2009:

    Ho jon,
    Basically, you create a FakeRepository class that is a concrete implemetation of your IRepository. You can follow the Rob Conery’s MVC Store Front screencasts for an example on how to test your repositories.

    http://blog.wekeroad.com/mvc-storefront/mvc-storefront-part-1/

    Hope it helps,
    Julian

  7. 7 Joao Araujo said at 11:15:33 on February 1st, 2009:

    Nice article, thanks!

  8. 8 behnam said at 10:41:57 on May 5th, 2009:

    hi
    nice articel but There is something about using repository pattern i cant understand. What is difference between repository pattern and n tier architecture? IProjectRepository (in this sampel) .
    isnt the same as bussines login in n tier architecture.
    thanks for your attention

  9. 9 DurgaPrasad said at 14:40:07 on May 5th, 2009:

    Hello Julian,

    Can you pls publish the complete source code for this application. ?

    Thanks

  10. 10 julian said at 12:19:02 on May 11th, 2009:

    @behnam

    I’m thinking of a repository as a part (tier) of my n-tier design. Probably the question should be “what’s the difference between DAL and repository?” and it’s all about interpretation and context. In my projects i’m using LINQ2SQL as DAL generator and the repository as a bridge between DAL and the service layer.

    IMO, the idea behind a repository is that it encapsulates all persistence logic and dependencies on infrastructure from the rest of your application. When your application needs a Project object, it shouldn’t have to know whether it is coming from SQL Server, XML file, or MySQL. Once you have that de-coupling, any changes you make to your persistence story have no effect on the rest of your application.

    @DurgaPrasad

    This is not a complete application but a simple experiment. I’m working on a simple ASP.NET MVC CMS in my spare time at home but i have nothing ready – only a bunch of unit tests, repositories and LINQ partial classes :)

  11. 11 bb said at 16:16:27 on May 23rd, 2009:

    hi
    can you give me a puicture of using repository pattern in enterprize application.
    regard

  12. 12 Ratndeep said at 12:21:05 on October 28th, 2009:

    I was looking for the info on asp.net mvc with repository pattern and u have given me the all basic understanding.Thanks for this.


Leave a Reply