We pay for user submitted tutorials and articles that we publish. Anyone can send in a contributionLearn More
In the first part of this series we didn’t really look at the MVC framework. We talked about what it is and what it does but didn’t look at any code. We did however plan out what we wanted our application to do and created our database schema that will support our application. In this part we are going to jump in and get an MVC Application created and look at the Model portion of the application. We’ll create our domain objects and data repositories. It is important to note that I will be using the Repository Pattern with Pipes and Filters Pattern. So we’ll have our data repositories and their relevant filters. We will then create data service objects that encapsulate the repositories. Also, I will be using LINQ To SQL to interact with the database. If you prefer a different method of data access feel free to use something else. Finally, before we get started, I will not be writing unit tests for this series, at least not showing them in the posts, in order to keep things simple and to keep the posts from getting too long.
I’ll assume you have already created the database schema that we talked about in the part 1. It is important to have the Data Connections setup in the Server Explorer as this will be required to create the LINQ to SQL classes. So, in Visual Studio create a new project and use the settings like the screenshot below.
When you click OK, VS will create a new MVC application for you. It will contain a couple Controllers and Views that make up the MVC demo application. We’ll ignore this for now. To keep things simple I will be using the layout of the demo app but I will be deleting some files later on.
In the Server Explorer you should have your Data Connection setup to your database with our application tables. Creating the data diagram is super easy. All you do is drag each table from the Server Explorer to the design surface and VS will create the diagram and relationships for you. Also, after you compile your application you will have model objects that reflect your database tables and their relationships.
As I said earlier I am using the repository pattern to handle my data access. For each model I will create an interface and repository class for interacting with that model. Below is the interface and class for the Tasks model repository. internal interface
This simple repository has a method that fetches all the Task objects from the database through LINQ To SQL. Notice the .ToList() on the methods return statement. This turns the dynamic object tasks into a List<Task> to be returned.
Because our repository returns IQueryable we can apply a filter and use LINQ to filter the existing results. Notice that the filter also returns IQueryable. This allows you chain filters making advanced queries a breeze.
Now that we have a repository and filters in place we can construct our data service that our application will use. It may seem like extra work to wrap the repository in a service but it allows you to make changes to the repository and filters without having to touch any application code. This is a huge benefit from just a small amount of extra work.
Now here is how we would use the service in our application.
Pretty simple, huh?
The classes that LINQ creates from our data diagram go beyond just an identical representation of our database tables. LINQ takes the relationships into accounts. For example, we used our Tasks table in the code above to create a TasksRepository. This Id column of this table is a foreign key in the TodoItems table which links individual to do items to a specific task. The IQueryable<Task> that is returned from the GetTasks method is a collection of Task objects. So in the generated Task model objects that instances of the model will have an EntitySet<TodoItem> collection as part of the instance. LINQ really is powerful in this way. It gives us huge power while simplifying our code. Also, if you change the Delay Loaded property of the TaskId foreign key in the TodoItems table you have instant Lazy Loading with no work at all. Makes you wonder why you ever tried to write that functionality yourself doesn’t it?
So we have setup our application, configured LINQ To SQL to generate our Model classes, and we have look at how to implement a Repository Pattern for data access with filters. That is a lot to take in but I hope you see the potential and power of where we are going with ASP.Net MVC and will continue to read this series. Again we didn’t really look at ASP.Net MVC. Don’t be angry. We were laying the foundation first. I promise there will be some juicy MVC bits in the next article. I plan to look at routing and controllers in the next post and if I don’t get too long winded with those we may take a peek at views. To make sure you don’t miss a beat grab the Dev102 RSS feed. You may also be interested to follow what I have to say on my web development blog or grab my RSS feed. Enjoy!
Tags :ASP.NET MVCLINQModelMVCPatternrepositorySQL
Copyright © 2012 Dev102.com
Breeze : Designed by Amit Raz and Nitzan Kupererd