API Services and Microservices

• A layered architecture with some layers are independent projects and some layers live inside app itself
  • Data access layer i.e. data project, API client project
  • Service layer (inside app)
  • API layer (API project itself)
  • You can have “Repository Layer” in between Service layer and Controllers, but I normally replace Repository Layer with EF Core data project
    • theoritically DbContext itself is repository
    • DbContext has properties of repository i.e. Unit of Work
• Data access layer as an independent project
  • Data project
    • When using EF Core
    • Naming: <solution_name>.<API_project_name>.Data i.e. Foo.XxxApi.Data
    • Data project as data access layer
      • Data project is the EF Core (scaffolded) project containing DbContext and Entities**
      • Will only deal with data access (not more, not less)
      • Will be used by Services and do not use data project directly in Controllers
  • API client project
    • When an API is calling other APIs or a client app consuming an API
    • Naming: <solution_name>.<calling_API_name>.Client i.e. Foo.BazzApi.Client
• Request and Response models in an independent project (library project)
  • For API Service/Microservice, Request and Response models should be in an independent shared (library) project
  • Request and Response models will be shared by both API project and API client project (client project will be used by app that is consuming API)
  • In case of a shared project, it is easy to change Request and Response models (do once)
• Service layer
  • Should be inside the API project
    • Service layer would not be shared by any other project (most probably), so there is not reason to make it an independent project
    • Services might use Framework specific feature, so it should live inside the app project
  • All logic and processing should be here
  • Uses data access layer
  • Uses AutoMapper to map from entities to Request/Response and vice versa
  • Uses helper classes i.e. Utilities
  • Should be unit tested (xUnit + AutoFixture + Moq)
• API project
  • Controllers will be dumb and should ask to service for everything
  • Will contain helper classes i.e. Utilities, Extension Methods etc.
  • Might contain POCOs that will be used internally (i.e. for transfering data between layers)

API project: ‘Foo.Api’ (Foo is the solution name, EF Core Data project: ‘Foo.Api.Data’)

- AppData (.json, .mdf)
- Services
  - IXxxService.cs
  - XxxService.cs
- Controllers
- Exceptions
- Utils
- ExtensionMethods
- Middlewares
- Filters
- AutoMapper

Solution Diagram for API service or Microservice

Solution Diagram for API service consumed by multiple clients of same organization

Blazor WebAssembly

- AppData (.json, .mdf)
- Services
  - IXxxService.cs
  - XxxService.cs
- Controllers
- Exceptions
- Utils
- ExtensionMethods
- Middlewares
- Filters
- AutoMapper

Blazor Server

- AppData (.json, .mdf)
- Services
  - IXxxService.cs
  - XxxService.cs
- Controllers
- Exceptions
- Utils
- ExtensionMethods
- Middlewares
- Filters
- AutoMapper

ASP.Net Core MVC Web Applictaion

Using Database

- AppData (.json, .mdf)
- Services
  - IXxxService.cs
  - XxxService.cs
- Controllers
- Exceptions
- Utils
- ExtensionMethods
- Middlewares
- Filters
- AutoMapper

Consuming API

- AppData (.json, .mdf)
- Services
  - IXxxService.cs
  - XxxService.cs
- Controllers
- Exceptions
- Utils
- ExtensionMethods
- Middlewares
- Filters
- AutoMapper

ASP.Net Core Razor pages

Same as ASP.Net Core MVC Web Applictaion