In previous article, we have written repositories for blog demo. In this article, let’s write business layer and API layer. After adding API layer, we would be able to use swagger to test the APIs. This would help for implementing next functionalities required for solution.
Let’s create two class libraries:
- Blog.Business.Contracts – to contain interfaces for business layer logic. You would need to add references of
Blog.Data.EFprojects as we are using entities defined in
Blog.Data.EFas data objects.
- Blog.Business – to contain three business logic classes, which implement three business layer interfaces from Contracts namespaces. The respective repositories can be injected in these classes.
Contracts without Data Objects
Note that we are not creating layer specific data objects. Ideally, it is good practice to create layer specific data objects. This would help hiding lower layers completely from the above layers. It would also help layers decoupled from one another.
For the sake of this demo, we are just creating layers and layer specific interfaces which defines operations to be implemented by that layer. But we are not adding layer specific data objects – to keep the article short. If you want to add layer specific data objects, you can add them and then use AutoMapper to map the objects from one layer to its immediate next layer.
Also, as we have done fore implementing repositories, we can create a base interface and an abstract base class for business layer. The abstract class will implement all basic methods hence the concrete implementations would be mostly empty. Below snippet shows base interface and abstract base class for business layer logic.
Note that initially such common base class might save time for setting up the application. Business rules may evolve over time, and some applications might not need a common implementations for business layer.
First thing, let’s add the connection string for our Blog database in
appsettings.json. Next, in
startup.cs, we need to register the BlogContext and set the connection string on the context.
Ideally, database level entities should not be exposed to the API callers. Hence we are going to create few models. Initially, API models and DB entities may have same columns. Over the time, we can define API models in such a way that they fulfil requirements of the application which calls the API.
Every higher layer class is dependent on the interfaces provided by the lower layers. Hence, we need to setup dependency injection so that DI can inject appropriate interface implementations.
Below code snippet shows
ConfigureServices method from
Startup.cs after all above mentioned configurations are done.
Then we can create respective controllers. Mainly we are interested in these 3 controllers for the sake of this demo:
- PostsController – which has methods for
Get, Create, Update and Deleteposts.
- TagsController – which defines methods for
Get, Create, Update and Deletetags
- CategoriesController – which defines methods for
Get, Create, Update and Deletecategories
Below is one of the controller (
PostsController), showing how the code from controller looks like.
Run and Verify
When we run the API project, it would open Swagger page. We can try calling different APIs to ensure that they are working as expected.
And that’s it, we implemented API layer, business layer and data access layer required for a blog. This is still incomplete. The related data loading is not setup yet. In coming articles, we will try to see how related data can be loaded.
I hope you find this information useful. Let me know your thoughts.