Skeleton for Vertical Layered Web API in .NET CORE

…with fluent validation and automapping…

image by Vecteezy.com

Some Description

So this skeleton app shows how an application could be split into vertical layers. This has multiple advantages (again see Horizontal and Vertical Layers in Software Development). Furthermore it shows with one example the flow of the data and connections from top (controller/application layer) to bottom (data layer). The data layer is only pseudo code and does not persist stuff, to focus on the layering and communication stuff.

  • Business Layer
  • Data Layer
  • WebApi.Configuration (DI bootstrapping / connecting the layers together)
  • WebApi.Common (Common stuff for the web api)
  • Application (The implementation of the application layer)
  • Application.Contract (The access to the application layer from outside the application layer)
  • Business (The implementation of the business layer)
  • Business.Contract (The access to the business layer from outside the business layer)
  • DataLayer (The implementation of the data layer)
  • DataLayer.Contract (The access to the data layer from outside the data layer)

Application Layer

The application layer is used here in this example by the web api project (Controllers). But the Controllers has only access to the application layer contracts. This allows us to avoid unwanted direct connection to use the implementation directly or to access business entities which knows the application layer implementation, but should not possible to expose by the api to the “outer world”. The application layer implementation knows only about the business layer contracts to communicate with it.

Business Layer

The business layer knows only about the data layers contracts. The business lay exposes only interfaces to use the layer and the business entities.

Data Layer

The data layer knows only about the database or storage where all the data is persisted. The contracts from the data layer should only be used from the business logic to make sure that persisting data follows the rules inside the business layer. It is the connection to database and or storage. If provides repositories to store and get items from the database/storge.

Comments

This splitting is for the most services to much, but it demonstrates very well how the layer can securely communicate to each other. This pattern fits best for situations where no object relation mapper is used, because in entity framework the business entities are the tables in the data layer. So this layer is mostly a little overdone.

like to create

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store