Member-only story
N-Tier Architecture in ASP.NET Core
Part 4: Build layered architecture for separation of concern, scalability and maintenance
From previous articles of the series it was demonstrated to setup REST API and architectural changes to separate concerns into repositories, controllers.
However for better modularity and separation of concern, separate layers can be configured for each process. Hence each layer is independent of each other and can be replaced by multiple implementations if needed. Layered design of REST API can be used to demonstrate usages of this architectural pattern.
Each of these layers should be Single Responsibility to avoid tight coupling and to support Separation of Concern. (Note that tiers and layers are used interchangeably but there is slight difference. Layer is known to be logical separation, where tier is actually physical separation. This is where some layers could be hosted in different physical locations due to independence of layers.)
Classical N-Tier Architecture
3-Tier Architecture is typical N-Tier design where application is separated into 3 different layers with each one having its own task. Here layer’s assigned task are maybe defined in respect to ASP.NET Web API terms.
- DATA ACCESS LAYER
This layer handles database interaction of the application, and only location where database related queries are done. Here queries might vary according to underlying database, but these inner queries are not exposed. Functions related to CRUD are exposed publicly from this layer, where application can execute these methods. Then data access layer would connect to database, execute required query and return results to other layers, and thereby keeping other layers abstract from database integration. Typically data access layer is added as repositories.
BookRepository → Insert(book)
AuthorRepository → GetByName(firstName)- BUSINESS LOGIC LAYER
