Creating a simple Todo list with Angular2 and asp.net core – Part 2

by Alex on June 21, 2016

If you recall from part 1, we finished creating the site using Yeoman and viewed our new creation in the browser.

Before we get started on the Angular2 bits, we need to do a little coding and configuration on the server side. Lets look at that now.

The Database

The database on the backend of this app is going to be Sqlite. Im going to connect to it using Entity Framework. In order to use EF, I need to reference the correct libraries in my project.json file. Lets add those dependencies now:

alt text

Once Ive added the references to my project.json file, I jump out to the command prompt to run “dotnet restore” again to be sure I have all the required bits.

alt text

Now that we have EF in place, lets turn our attention to the todos.

Thinking about what we’re building

It will probably benefit us greatly to stop and think a moment about what we are building. As the title implies, we are building a simple todo list but what makes up a todo? Well, for the purposes of this post, we are going to keep it simple.

A todo is made up of the following properties?

  1. An id
  2. a Name
  3. a boolean flag indicating if the todo is complete

Let create that simple class now. Looking at VS Code and what Yeoman created for us, where should we put this class?

alt text

A Models folder was not created for us, so Ill go ahead and add that Models folder now. Now we need to create the class for TodoItem.cs. We could just create a new empty file but we can use Yeoman again here to make our lives a bit easier.

At the command prompt Ill type “yo aspnet –help” to get a full list of all the commands yeoman knows about for the aspnet generator.

alt text

You can see all the subgenerators that this aspnet generators provides. So, If I want to create a Model class I can use the yo aspnet:Class generator and yeoman will create the class for me. Another good time saver. Ill just navigate to the Models folder and run the command.

alt text

Ill edit the newly created file to include the using statments for Entity Framework and the annotations that will be used by the migration to create the table and columns in the db.

alt text

Next up, the Repository

With our simple model in place, let create the Repository. We will be handling simple CRUD operations with this app so the interface is pretty straight forward. Ill use Yeoman again to create these files.

alt text

The last file that I created above is the TodoContext. This is a simple file that EF uses when interacting with the database. You can read more about working with DbContext here

alt text

alt text

The code for the Repository implementation gets a little long to display here so check it out on github if you’re interested.

With our model and repository now in place, we can create the migration we need and configure the Startup.cs file to load our repository into the DI Container. Lets configure the Startup.cs file first.

alt text

If you notice my fancy arrows above, you can see that I appended the AddJsonOptions() method call and setup the contract serializer. This will make sure that we have camel case property names on the client side while using Pascal cased names on the server.

The second arrow is registering our ITodoRepository with the DI Container. Essentially, what this says is “when someone asks for an ITodoRepository, give them a TodoRespository”…. Easy Peasy!

Now lets create and run those EF migrations.

alt text

You can read more about the EF Command line tools here but what I’ve done here is pretty straight forward. I created a new migration called “TodoList” and then applied that Migration to the Database. Any Ruby on Rails developers out there should feel very at home with this method as its pretty much exactly the same as rails.

With that complete, we can check to see if our database was created in VS Code.

alt text

You can see our newly created todo.db in the bin folder and all of the files we created above in the Models folder.

OK, so whats next? We have our database and table to hold data and we have a repository to access that data. Now we need to turn our attention to the Controller. The controller will provide the API that the Angular app will make calls to in order to get/post/put and delete data. The yeoman generator did create a controller for us called HomeController. Lets look at that:

alt text

Looking at this controller, we can see that it wont do. This controller is setup to return views but we want to access an API for data only. Microsoft had something in the past called Web API that did just that but Web API is now baked into the same framework as the regular Controllers. All Controllers now inherit from the Controller base class regardless of type.

So what to do? Yeoman to the rescue again.

Remember that long list of Subgenerators that we looked at at the beginning of this post? No? go take a look, Ill wait…………..if you look at the bottom of that list you’ll see there is a sub generator for WebAPIController. Great news…..lets use that!

Ill just navigate to my Controller folder and…..

alt text

and it gives us exactly what we need.

alt text

With our new controller in place, we can fire up the site and browse to http://localhost:5000/api/todo and we should get back an array with 2 values just as shown in the Get() method in the controller.

With the controller in place, Ill call this post a wrap.

In the next post we will finish our work on the server side by:

  1. Setting up the controller to access the database
  2. Test the API via a browser as well as do a quick test using Postman

Once that’s all working correctly, we can turn our attention to the client side and the Angular bits.

Until next time…. Thanks for visiting.

Leave a Comment

Previous post:

Next post: