Boilerplate – Layered Architecture Rest API using .Net Core 3.1


I am planning to create a collection of ready-to-start (development) production-ready solutions/repo boilerplates for .Net core 3.1 REST APIs with different architecture and patterns for various use cases and scenarios.

I am starting the mission with a version of layered architecture with a Repository pattern and entity framework core as ORM. I’ve followed the pattern of microservice and creating individual micro-API’s which can be scalable independently.

I still believe there are scenarios for building REST API using the layered architecture and repository pattern, and of course, this has some relevance now as well.

The code is available to download/clone from github here.


The architecture pattern I have followed is the bottom up Presentation Layer -> Business layer -> Data layer , all of the layers are loosely couple using DI container available in .Net Core.

alt text


Rest API : .net core 3. Web API Project.

ORM : EntityFrameworkCore 5.0 is used for ORM.

Unit Test: MS Test is used for unit testing the service/business layer classes and Moq framework is used to mock the data layer.

Validation : Fluent validation is used for the validation. (More about Fluent validation here)

Documentation: The swagger documentation has been used and it is configured using Swashbuckle in the middleware. ( More here)

Data Layer : Data layer is built using the repository pattern.

Authentication : AspNetCore.Authentication.JwtBearer Package is used to introduce JWT token-based authentication and authorization. This can be easily replaced with AAD or any other OAuth-based identity provider by configuring the middleware in start-up and changing the AutheticationService in the service layer. As of now, role-based authorization is also implemented using the JWT token.


Once cloned/downloaded you can run this API in IISExpres, IIS or Kestrel servers.


Please feel free to contribute to the mission. Suggestions, changes, or fixes are most welcomed, please feel free to clone the repo, create a branch and make your changes and submit a pull request.

Importance of Code Review


In the era of rapid development and agile model maintaining quality of the code base is always challenging for every organization and teams. Code review plays an important role to maintain the code base clean and good. It should be always a two way healthy debate between the developer and the reviewer, which will results a lot more better result to code base as well as the entire team.


During my initial days of coding code review is the process of getting your senior developer/lead/architect time so that they can sit at you machine and verify the changes and tell their comments. This includes healthy discussion and debate on the code as well. Once they approved only we were able to check in/commit the changes.

Now we do have different tools and creating a pull request , the reviewers can review the code and add their review comments and you can resolve the comments as well.

Self Review

In both cases always do a self review before you are assigning your pull request to a reviewer. You can create a self review check list in the team and follow the same which should include

  • Make sure you are aware , judiciously following and verifying the principles like DRY (Do not repeat your self) , KISS (Keep it simple and short) , Single Responsibility Principle etc.
  • Coding standards – the standards depends on your language and chosen by the team.
  • Naming conventions and standard – always good to write code which is self explainable without comments also the case standards your team following .
  • Best practices – Make sure you are following the best practices based on your language, class library and the frame work.
  • Format your code – so that it looks beautiful – make sure that you follow proper spacing, indentation ( there are tools and shortcuts available for doing this in all modern editors) so that your code looks neat and clean.
  • Make sure to run the unit test and all pass , run lint / code analysis tools and correct all errors and warnings.


Reviewers should be always open for discussion and understand the view of the developer and you should have healthy debate with pros and cons of both your approach and developer approach. This will improve the morale of the entire team as well as knowledge.

Do a full review and add all comments in advance so that the developer can resolve all comments at once. Make sure to consider all aspects of the code including the impact on the current functionalities as well. Also consider all the principles , anything missed from the self review checklist.


Peer Review

Also encourage the peer review before the senior level review so that the efficiency and quality of entire team shall improve. This will help to build the next level of the team and you can follow the code quality religiously across the team.

Happy code review 🙂

Crafting Beautiful and Quality Code

I have always used to spend time to think about the best name to choose for a variable , function or a class. While doing the peer review of the code I always suggest my team to follow this as well. Even though you are communicating with the machine with the code you should always make it readable to you peers who will be going to read it and understand what it is supposed to do.

Thinking in React

I have been working in React, Flux and Redux for last few years and have gone through numerous success and failure experiences in it. This experience have given me a fare bit of knowledge on React and I thought of sharing it with you.

The major one which strikes me most is about “ thinking in react”, majority of new react developers have failed to adopt react as such because of the lack of “thinking in react way”.

avaScript and JavaScript class libraries and frameworks undergoes massive evolution for the past few years. React stood in front among that journey which allows us to develop rich client based highly performing single page applications.

Understand it correctly

The main part of learning react starts with understand the key things correctly. Props/State, life cycle events and the way of constructing a react component correctly. It is always good to have a basic understanding on what is happening behind the scene before start using the same. Try to get a basic knowledge of Reconciliation, Diff algorithm and the component tree then it is easy to understand that how the component get re-rendered , when we need to use or change props and state.

Understanding the life cycle events is really important because writing wrong thing in wrong event may end up in hell. Get a clear understanding on each life cycle like when it will get triggered and what action should we do in that. For example if you are writing some code to change the state unconditionally in componentDidUpdate() it will end up in an infinite re-rendering. Another example is attaching an event listener in didUpdate(), which will end up with n number of reference and the memory usage will rise.

Do you really need a state management mechanism by default?

No, is the answer. You don’t need one unless it is really painful for you to manage the state using private state. Nowadays there is trend like going for redux or any state management by default with every react project. Believe me , you can build cool apps with private state with less complexity and maintainability. The new Context API offers you great way to pass data from parent to grand child and which will help you to avoid unwanted props in intermediate components. I suggest you to think twice before you choosing a state management mechanism. Worth reading a good article from Dan Abramov on this here.

Understand your component structure

Ultimately you are going to create some html which will be rendering in the browser, keep this in mind while you are creating the components. A component does this for you in react, while render it will returns the html.Our aim here is to reuse the components as much as possible so design your component as tiny as possible. Once you got the html take a look and decide which all components need a state and which are not. Don’t go for a state until you really need that, avoid the hassles of state management by creating it as a stateless component.

Understand the new release Roadmap

React has their release Road map where they describes the journey towards asynchronous rendering and concurrent rendering. Keep this in mind because all the new releases coming with changes align with this road map. So we need to careful while developing our app and that should use the pattern or architecture which align with this road map so that it will be easy to upgrade to newer version and use those interesting features quickly.

Best practices in React and Flux


React is a wonderful class library which can be used to develop rich client application by ensuring better performance. Flux is the architecture which gives the beauty of uni-directional data flow and immutability of data. React+Flux is always a good choice while you starting your web application.I would like to share some thoughts on the good practices we can follow while developing an app using react and flux.

No direct store update

The unidirectional data flow gives the beauty of single source of truth, however it is a choice. Flux doing nothing to prevent you making it bidirectional, you can always update the store from your component directly with out initiating an action creator and action. If you want to follow flux don’t do this.

Call setState appropriately

One another mistake is calling setstate inside render. You can call setState anywhere other than render. However try to avoid unconditional setstate inside componentDidupdate() as it may lead to infinite re-rendering since didUpdate calls whenever a component has re-rendered.

Avoid updating the DOM directly and use ref wisely

Since react is doing the job of DOM update using virtual DOM it is a bad practice to update the DOM directly using conventional methods.Instead use ref to read the DOM and update the DOM react way by calling setState and re-rendering.

Always use unique key to the components

React internally identifies the components using key so it is important to make sure that you are using unique names for the react components.

vDo not add listeners in willReceiveProps or didUpdate().

Do not add event listeners in componentDidUpdate() and componentWillReceiveProps()

Adding event listeners in didUpdate and willReceiveprops is a bad idea as both life cycle events (willReceiveprops is deprecated from the latest version 16.4 onward) will trigger more than once based on props change or state change. So adding listeners in those event cause multiple reference of the event listeners and cause memory leak.

Stateless as much as possible and Tiny Components

It is always good to go for the stateless and tiny components whenever possible. This can improve the performance by avoiding the life cycle.

Bind the callback functions inside the constructor

Avoid binding the context while passing a call back function as prop to child component. If you are passing like that it will be creating a new reference every time and cause re-render of your pure child component. Instead bind the context in constructor and pass the same as prop.

class Parent extends React.Component{
    // Bind the context here
    this.callBackFunc = this.callBackFunc.bind(this)
    return ( <Child callBack={this.callBackFunc});