Introduction
I have been practicing and reading a lot about RESTful services for the past few days. To my surprise, I could not find a complete series of practical implementations of ASP.Net Web APIs on the web. My effort in this series will be to focus on how to develop basic enterprise-level application architecture with Web APIs.
We'll be discussing less theory and doing more practice to understand how RESTful services can be created using an ORM. We choose Entity Framework here. My first article in the series is to set up a basic architecture of a REST service-based application. Later on in my future articles, I'll explain how to follow best standards to achieve enterprise-level architecture.
Roadmap
My road map for the series is as follows:
I'll purposely use Visual Studio 2010 and .NET Framework 4.0 because there are a few implementations that are very hard to find in .NET Framework 4.0, but I'll make it easy by showing how to do it.
REST
Here is an excerpt from the Wikipedia:
“Unlike SOAP-based web services, there is no "official" standard for RESTful web APIs. This is because REST is an architectural style, whereas SOAP is a protocol. Even though REST is not a standard per se, most RESTful implementations make use of standards such as HTTP, URI, JSON and XML.”
I agree to it. Let's do some coding.
Setup database
I am using SQL Server 2008 as a database server. I have provided the SQL scripts to create the database in SQL Server, you can use it to create one. I have given WebApiDb as my database name. My database contains three tables for now; they are Products, Tokens and User. In this tutorial we'll only be dealing with a product table to do CRUD operations using Web API and Entity Framework. We'll use Tokens and Users in my future article. For those who fail to create database using scripts, here is the structure you can use:
Web API project
Open your Visual Studio. I am using Visual Studio 2010, you can use Visual Studio version 2010 or above.
Step 1
Create a new Project in your Visual Studio as in the following:
Step 2
There after, choose to create an ASP.Net MVC 4 Web Application and provide it the name of your choice, I used WebAPI.
Step 3
Out of various type of project templates shown to you, choose Web API project as in the following:
Once done, you'll get a project structure like the one shown below, with a default Home and Values controller.
You can choose to delete this ValuesController, since we'll be using our own controller to learn.
Setup Data Access Layer
Let's setup or data access layer first. We'll be using Entity Framework 5.0 to talk to the database. We'll use the Generic Repository Pattern and Unit of Work pattern to standardize our layer.
Let's have a look at the standard definition of Entity Framework given by Microsoft:
“The Microsoft ADO.NET Entity Framework is an Object/Relational Mapping (ORM) framework that enables developers to work with relational data as domain-specific objects, eliminating the need for most of the data access plumbing code that developers usually need to write. Using the Entity Framework, developers issue queries using LINQ, then retrieve and manipulate data as strongly typed objects. The Entity Framework's ORM implementation provides services like change tracking, identity resolution, lazy loading and query translation so that developers can focus on their application-specific business logic rather than the data access fundamentals.”
In simple language, Entity Framework is an Object/Relational Mapping (ORM) framework. It is an enhancement to ADO.NET, an upper layer to ADO.NET that gives developers an automated mechanism for accessing and storing the data in the database.
Step 1
Create a new class library in your Visual Studio and name it DataModel as shown below:
Step 2
In the same way, create one more project, again a class library, and call it BusinessEntities as in the following:
I'll explain the use of this class library soon.
Step 3
Move on to your DataModel project. Right-click on it and add a new item in the list shown, choose ADO.Net Data Model and name it WebApiDataModel.edmx.
The file .edmx will contain the databse information of our database that we created earlier, let's set this up.
You'll be presented a wizard as follows:
Choose generate from database. Choose Microsoft SQL Server as shown in the following image:
Click Continue, then provide the credentials for your database, in other words WebAPIdb and connect to it as in the following:
You'll get a screen showing the connection string of the database we chose as in the following:
Provide the name of the connection string as WebApiDbEntities and click Next.
Choose all the database objects, check all the check boxes and provide a name for the model. I gave it the name WebApiDbModel.
Once you finish this wizard, you'll get the schema ready in your datamodel project as follows:
We've got our schema in-place using Entity Framework. But a bit of work remains. We need our data context class and entities through which we'll communicate with the database.
So, moving on to the next step.
Step 4
Click on Tools in Visual Studio and open the Extension Manager. We need to get a db context generator for our datamodel. We can also do it using the default code generation item by right-clicking in the edmx view and add a code generation item, but that will generate an object context class that is heavier than the db context. I want a lightweight db context class to be created, so we'll use the Extension Manager to add a package and then create a db context class.
Search for Entity Framework Db context generator in the online galary and select the one for EF 5.x as in the following:
I guess you need to restart Visual Studio to get that into your templates.
Step 5
Now right-click in the .edmx file schema designer and choose “Add Code Generation Item...”.
Step 6
Now you'll see that we have the template for the extension that we added, select that EF 5.x DbContext Generator and click Add.
After adding this we'll get the db context class and its properties. This class is responsible for all database transactions that we need to do, so our structure looks as shown below.
Wow, we ended up with errors. But we got our db context class and our entity models. You can see them in our DataModel project. Errors? Nothing to worry about , it's just we did not reference Entity Framework in our project. We'll do it the right away.
Step 7
Go to Tools -> Library Packet Manager -> Packet Manager Console.
You'll get the console in the bottom-left of Visual Studio.
Select dataModel project and rovide the command “Install-Package EntityFramework –Version 5.0.0” to install Entity Framework 5 in our DataModel project.
Press Enter. And all the errors become resolved.
Generic Repository and Unit of Work
You can read about the Repository Pattern and creating a repository in detail from my article:
Repository Pattern in MVC3 Application With Entity Framework: Part 5
Just to list the benefits of the Repository Pattern:
- It centralizes the data logic or Web service access logic.
- It provides a substitution point for the unit tests.
- It provides a flexible architecture that can be adapted as the overall design of the application evolves.
We'll create a generic repository that works for all our entities. Creating repositories for each and every entity may result in lots of duplicate code in large projects. For creating a Generic Repository you can follow:
Generic Repository Pattern in MVC3 Application With Entity Framework: Part 6
Step 1
Add a folder named GenericRepository to the DataModel project and to that folder add a class named Generic Repository. Add the following code to that class that serves as a template-based generic code for all the entities that will interact with the databse as in the following:
- #region Using Namespaces...
-
- using System;
- using System.Collections.Generic;
- using System.Data;
- using System.Data.Entity;
- using System.Linq;
-
- #endregion
-
- namespace DataModel.GenericRepository
- {
-
-
-
-
- public class GenericRepository<TEntity> where TEntity : class
- {
- #region Private member variables...
- internal WebApiDbEntities Context;
- internal DbSet<TEntity> DbSet;
- #endregion
-
- #region Public Constructor...
-
-
-
-
- public GenericRepository(WebApiDbEntities context)
- {
- this.Context = context;
- this.DbSet = context.Set<TEntity>();
- }
- #endregion
-
- #region Public member methods...
-
-
-
-
-
- public virtual IEnumerable<TEntity> Get()
- {
- IQueryable<TEntity> query = DbSet;
- return query.ToList();
- }
-
-
-
-
-
-
- public virtual TEntity GetByID(object id)
- {
- return DbSet.Find(id);
- }
-
-
-
-
-
- public virtual void Insert(TEntity entity)
- {
- DbSet.Add(entity);
- }
-
-
-
-
-
- public virtual void Delete(object id)
- {
- TEntity entityToDelete = DbSet.Find(id);
- Delete(entityToDelete);
- }
-
-
-
-
-
- public virtual void Delete(TEntity entityToDelete)
- {
- if (Context.Entry(entityToDelete).State == EntityState.Detached)
- {
- DbSet.Attach(entityToDelete);
- }
- DbSet.Remove(entityToDelete);
- }
-
-
-
-
-
- public virtual void Update(TEntity entityToUpdate)
- {
- DbSet.Attach(entityToUpdate);
- Context.Entry(entityToUpdate).State = EntityState.Modified;
- }
-
-
-
-
-
-
- public virtual IEnumerable<TEntity> GetMany(Func<TEntity, bool> where)
- {
- return DbSet.Where(where).ToList();
- }
-
-
-
-
-
-
- public virtual IQueryable<TEntity> GetManyQueryable(Func<TEntity, bool> where)
- {
- return DbSet.Where(where).AsQueryable();
- }
-
-
-
-
-
-
- public TEntity Get(Func<TEntity, Boolean> where)
- {
- return DbSet.Where(where).FirstOrDefault<TEntity>();
- }
-
-
-
-
-
-
- public void Delete(Func<TEntity, Boolean> where)
- {
- IQueryable<TEntity> objects = DbSet.Where<TEntity>(where).AsQueryable();
- foreach (TEntity obj in objects)
- DbSet.Remove(obj);
- }
-
-
-
-
-
- public virtual IEnumerable<TEntity> GetAll()
- {
- return DbSet.ToList();
- }
-
-
-
-
-
-
-
- public IQueryable<TEntity> GetWithInclude(System.Linq.Expressions.Expression<Func<TEntity, bool>> predicate, params string[] include)
- {
- IQueryable<TEntity> query = this.DbSet;
- query = include.Aggregate(query, (current, inc) => current.Include(inc));
- return query.Where(predicate);
- }
-
-
-
-
-
-
- public bool Exists(object primaryKey)
- {
- return DbSet.Find(primaryKey) != null;
- }
-
-
-
-
-
-
- public TEntity GetSingle(Func<TEntity, bool> predicate)
- {
- return DbSet.Single<TEntity>(predicate);
- }
-
-
-
-
-
-
- public TEntity GetFirst(Func<TEntity, bool> predicate)
- {
- return DbSet.First<TEntity>(predicate);
- }
-
-
- #endregion
- }
- }
Unit of Work
Again, I'll not explain in detail what Unit of Work is. You can Google about the theory or follow my existing article on MVC with Unit of Work.
To give a heads up, again from my existing article, the important responsibilities of Unit of Work are the following:
- To manage transactions.
- To order the database inserts, deletes and updates.
- To prevent duplicate updates. Inside a single usage of a Unit of Work object, various parts of the code may mark the same Invoice object as changed, but the Unit of Work class will only issue a single UPDATE command to the database.
The value of using a Unit of Work pattern is to free the rest of our code from these concerns so that you can otherwise concentrate on the business logic.
Step 1
Create a folder named UnitOfWork and add a class to that folder named UnitOfWork.cs.
Add GenericRepository properties for all the three entities that we got. The class also implements an IDisposable interface and it's method Dispose to free up connections and objects. The class will be as follows.
Now we have completely set up our data access layer and our project structure looks as shown below.
Setup Business Entities
Remember, we created a business entities project. You may wonder, since we already have database entities to interact with the database, why do we need Business Entities? The answer is as simple as, we are trying to follow a proper structure of communication and one would never want to expose the database entities to the end client, in our case the Web API, it involves a lot of risk. Hackers may manipulate the details and get access to your database. Instead, we'll use database entities in our business logic layer and use Business Entities as transfer objects to communicate between the business logic and the Web API project. So business entities may have different names, but their properties remain the same as database entities. In our case we'll add same-named business entity classes appended with the word “Entity” in our BusinessEntity project. So we'll end up having the following three classes:
Product Entity
- public class ProductEntity
- {
- public int ProductId { get; set; }
- public string ProductName { get; set; }
- }
Token entity
- public class TokenEntity
- {
- public int TokenId { get; set; }
- public int UserId { get; set; }
- public string AuthToken { get; set; }
- public System.DateTime IssuedOn { get; set; }
- public System.DateTime ExpiresOn { get; set; }
- }
User Entity
- public class UserEntity
- {
- public int UserId { get; set; }
- public string UserName { get; set; }
- public string word { get; set; }
- public string Name { get; set; }
- }
Setup Business Services Project
Add a new class library to the solution named BusinessServices. This layer will act as our business logic layer. Note that, we can use our API controllers to write the business logic, but I am trying to segregate my business logic in an extra layer so that if in the future I want to use WCF, MVC, ASP.Net Web Pages or any other application as my presentation layer then I can easily integrate my Business logic layer into it.
We'll make this layer testable, so we need to create an interface and in it declare CRUD operations to be performed over a product table. Before we proceed, add a reference for the BusinessEntities project and DataModel project to this newly-created project.
Step 1
Create an interface named IProductServices and add the following code to it for CRUD operations methods.
- using System.Collections.Generic;
- using BusinessEntities;
-
- namespace BusinessServices
- {
-
-
-
- public interface IProductServices
- {
- ProductEntity GetProductById(int productId);
- IEnumerable<ProductEntity> GetAllProducts();
- int CreateProduct(ProductEntity productEntity);
- bool UpdateProduct(int productId,ProductEntity productEntity);
- bool DeleteProduct(int productId);
- }
- }
Step 2
Create a class to implement this interface. Name that class ProductServices.
The class contains a private variable of UnitOfWork and a constructor to initialize that variable as in the following:
- private readonly UnitOfWork _unitOfWork;
-
-
-
-
- public ProductServices()
- {
- _unitOfWork = new UnitOfWork();
- }
We have decided not to expose our db entities to the Web API project, so we need something to map the db entities data to my business entity classes. We'll make use of AutoMapper. You can read about AutoMapper in my this article.
Step 3
Just right-click the project then select Extension manager, search for AutoMapper in the online galary and add it to the BusinessServices project as in the following:
Step 4
Implement the following methods in the ProductServices class.
Add the following code to the class:
Let me explain the idea of the code. We have the following 5 methods:
- To get a product by id (GetproductById): We call the repository to get the product by id. Id is a parameter from the calling method to that service method. It returns the product entity from the database. Note that it will not return the exact db entity, instead we'll map it with our business entity using AutoMapper and return it to the calling method.
-
-
-
-
-
- public BusinessEntities.ProductEntity GetProductById(int productId)
- {
- var product = _unitOfWork.ProductRepository.GetByID(productId);
- if (product != null)
- {
- Mapper.CreateMap<Product, ProductEntity>();
- var productModel = Mapper.Map<Product, ProductEntity>(product);
- return productModel;
- }
- return null;
- }
- Get all products from the database (GetAllProducts): This method returns all the products residing in the database, again we use AutoMapper to map the list and return it.
-
-
-
-
- public IEnumerable<BusinessEntities.ProductEntity> GetAllProducts()
- {
- var products = _unitOfWork.ProductRepository.GetAll().ToList();
- if (products.Any())
- {
- Mapper.CreateMap<Product, ProductEntity>();
- var productsModel = Mapper.Map<List<Product>, List<ProductEntity>>(products);
- return productsModel;
- }
- return null;
- }
- Create a new product (CreateProduct): This method takes the product's BusinessEntity as an argument and creates a new object of an actual database entity and inserts it using a unit of work.
-
-
-
-
-
- public int CreateProduct(BusinessEntities.ProductEntity productEntity)
- {
- using (var scope = new TransactionScope())
- {
- var product = new Product
- {
- ProductName = productEntity.ProductName
- };
- _unitOfWork.ProductRepository.Insert(product);
- _unitOfWork.Save();
- scope.Complete();
- return product.ProductId;
- }
- }
I guess you can now write update and delete methods. So the following is the code for the complete class.
The job is niw done at the business service level. Let's move on to the API controller to call these methods.
Setup WebAPI project
Step 1
Just add references for BusinessEntity and BusinessService to the WebAPI project, our architecture becomes like the following:
Step 2
Add a new WebAPI controller to the Controller folder. Right-click the Controller folder and add a new controller.
We get a controller as follows:
- using System;
- using System.Collections.Generic;
- using System.Linq;
- using System.Net;
- using System.Net.Http;
- using System.Web.Http;
-
- namespace WebApi.Controllers
- {
- public class ProductController : ApiController
- {
-
- public IEnumerable<string> Get()
- {
- return new string[] { "value1", "value2" };
- }
-
-
- public string Get(int id)
- {
- return "value";
- }
-
-
- public void Post([FromBody]string value)
- {
- }
-
-
- public void Put(int id, [FromBody]string value)
- {
- }
-
-
- public void Delete(int id)
- {
- }
- }
- }
We get HTTP VERBS as method names. The Web API is smart enough to recognize a request with the name of the VERB itself. In our case we are doing CRUD operations, so we don't need to change the names of the method, we just needed this. We only need to write the calling logic inside these methods. In my future articles of the series, we will work out how to define new routes and provide method names of our choice with those routes.
Step 3
Add logic to call Business Service methods. Just make an object of the Business Service and call its respective methods, our Controller class becomes like:
- using System.Collections.Generic;
- using System.Linq;
- using System.Net;
- using System.Net.Http;
- using System.Web.Http;
- using BusinessEntities;
- using BusinessServices;
-
- namespace WebApi.Controllers
- {
- public class ProductController : ApiController
- {
-
- private readonly IProductServices _productServices;
-
- #region Public Constructor
-
-
-
-
- public ProductController()
- {
- _productServices =new ProductServices();
- }
-
- #endregion
-
-
- public HttpResponseMessage Get()
- {
- var products = _productServices.GetAllProducts();
- if(products!=null)
- {
- var productEntities = products as List<ProductEntity> ?? products.ToList();
- if (productEntities.Any())
- return Request.CreateResponse(HttpStatusCode.OK, productEntities);
- }
- return Request.CreateErrorResponse(HttpStatusCode.NotFound, "Products not found");
- }
-
-
- public HttpResponseMessage Get(int id)
- {
- var product = _productServices.GetProductById(id);
- if (product != null)
- return Request.CreateResponse(HttpStatusCode.OK, product);
- return Request.CreateErrorResponse(HttpStatusCode.NotFound, "No product found for this id");
- }
-
-
- public int Post([FromBody] ProductEntity productEntity)
- {
- return _productServices.CreateProduct(productEntity);
- }
-
-
- public bool Put(int id, [FromBody]ProductEntity productEntity)
- {
- if (id > 0)
- {
- return _productServices.UpdateProduct(id, productEntity);
- }
- return false;
- }
-
-
- public bool Delete(int id)
- {
- if (id > 0)
- return _productServices.DeleteProduct(id);
- return false;
- }
- }
- }
Just run the application and we will get:
But now how do we test our API? We don't have a client. Guys, we'll not be writing a client now to test it. We'll add a package that will do all the work.
Just go to Manage Nuget Packages by right-clicking WebAPI project and type WebAPITestClient into the search box in online packages as in the following:
You'll get “A simple Test Client for ASP.NET Web API”, just add it. You'll get a help controller in Areas -> HelpPage like shown below.
Running the Application
Before running the application, I have put some test data in our product table.
Just hit F5, you get the same page as you got earlier, just append “/help” to its URL and you'll get the test client as in the following:
You can test each service by clicking on it.
Service for GetAllProduct:
To create a new product:
In the database, we get a new product as in the following:
Update product:
We get the following in the database:
Delete product:
In the database:
Job done.
Design Flaws
- The architecture is tightly coupled. Inversion of Control (IOC) needs to be there.
- We cannot define our own routes.
- No exception handling and logging.
- No unit tets.
Conclusion
We now know how to create a WebAPI and perform CRUD operations using an n layered architecture.
But still, there are some flaws in this design. In my next two articles I'll explain how to make the system loosely-coupled using the Dependency Injection Principle. We'll also cover all the design flaws to make our design better and stronger. Until then Happy Coding. You can also download the source code from GitHub.
Read more:
For more technical articles you can reach out to CodeTeddy
My other series of articles: