ASP.NET Core WebAPI Microservice Template with Postgres Db Backend. Non sevice-specific code is located in the Services.Core project. This could be included in all services or shared as a NuGet package. An xunit test project also exists for the Core project.
REST
routes defined in theController
classes accept and returnResource
objects- A
Swagger
page is hosted by default at the application root - The resources are validated automatically using
Validators
- Paging of results is provided by use of the
PagedRequest
andPagedResultSet<T>
classes. These may be enhanced to be specific to your domain. - The controllers map these resource objects to domain
Models
and pass them toServices
. - The services use a
UnitOfWork
to interact with one or moreRepositories
within a singleTransaction
- Repositories can use the generic
IRepository
implementationRepository
to get access to standardCRUDS
operations. Additional operations may be added.
There are some features that are not implimented yet:
- Identity & Access Management
- dotnet-new templates
- devcontainer support
UnitOfWork
is used to allow single transactions to span multipleRepositories
FluentValidation
is used to validate incoming Resource objects. This validation is displayed on the Swagger endpoint and helps enforce the Single Responsibility Principal (SRP) by keeping the validation logic out of the Resource object.IEntityTypeConfiguration<T>
is used to define the schema for each table using a fluent API. This is helps enforce the SRP.
Configuration for this service is provided through the appSettings[Environment].json file.
Additionally, configuration can be overwritten via environment variables.
For example, given the below configuration, the port for the database connection can be changed
to 4242 by setting the environment variable POSTGRES__PORT=4242
before running the application.
"Postgres": {
"Server": "localhost",
"Port": 5433,
"User": "yourusernamehere",
"Password": "yourpasswordhere",
"Database": "Schmoli.ServiceTemplate",
"Options": "Application Name=Schmoli.ServiceTemplate"
},
- API Controllers
- Inject Service and Mappers
- EF Core DB Context
- Configuration class for each table
IEntityTypeConfiguration<Model>
- Keeps model clear of any schema-related information (SRP)
- Automapper Profile(s)
- Map Resources <-> Entities and back
- EF Core migrations, autogenerated code.
- Service Domain Models
- Used for transmision from Services to Repositories
- Individual repositories for each model
- UnitOfWork interface and concrete implementation
- Base IRepository/Repository provide simple CRUDS operations
- Only need to implement advanced searches and nested item includes
- Customized Request objects for models (custom sorting, etc)
- Use simple PagedRequest when not needed
- Resource classes (previously DTO) used by controllers
- NOTE: No DataAnnotations required
- Interfaces and Implementations of Domain Services
- FluentValidation of Resources instead of DataAnnotations (SRP)