Blog.Core: an ASP.NET Core 8.0 API and RBAC skeleton for .NET teams

The problem Blog.Core solves for .NET API teams

Most .NET API projects start the same way: someone wires up dependency injection, adds a logging pipeline, writes a base controller, invents a permission model, and only then begins the actual product. Blog.Core is an attempt to hand you that first month of work already assembled. The README describes it as an out-of-the-box enterprise front-end/back-end separation framework built from a .NET Core API, a Vue 2.x front end and RBAC, and the repository ships the backend half plus pointers to three Vue projects (Blog.Vue, Blog.Admin, Nuxt.tBug) and a Blazor sample.

The audience is narrow but real. This is for a .NET developer or a small team that has decided on ASP.NET Core and wants a layered starting point with authentication, authorization, logging and data access already connected. It is not for someone who wants to add RBAC to an existing ASP.NET Core application: Blog.Core is a solution, not a NuGet package you drop into a host you already control. The README lists a NuGet section that is truncated in the repository document, so the exact packaging situation is something to check on the repository itself.

Layering, generic repositories and the four AOP aspects

The architecture is a conventional layered one. The README names Blog.Core.Api, Blog.Core.Common, Blog.Core.IServices, Blog.Core.Model, Blog.Core.Repository, Blog.Core.Services, Blog.Core.Tasks and Blog.Core.Serilog as the core layers that cannot be deleted, and calls the rest supporting layers you may remove if your business does not touch them. That split is the most useful piece of guidance in the document: it tells you where the load-bearing walls are.

Data access goes through SqlSugar, a domestic Chinese ORM, wrapped in a repository plus service plus interface pattern with cascade operations. The README states that the primary key type is configurable and that the framework supports switching between MySql, SqlServer, Sqlite, Oracle, Postgresql, 达梦 and 人大金仓. On startup it generates seed data automatically. Four AOP aspects cover logging, caching, auditing and transactions, and Serilog writes five kinds of log (audit, exception, request/response, service operation, SQL) into database tables across MySql, SqlServer, Sqlite, Oracle and Postgresql.

Authorization is button-level RBAC, and the README mentions one-click synchronization of interfaces and menus. The controllers it flags as undeletable are BaseApiController plus Department, Img, Login, Module, Permission, Role, TasksQz, User and UserRole. If you are evaluating the design rather than using it, that controller list is the clearest statement of what the framework considers its own domain.

Installing Blog.Core and getting the Sqlite seed database up

The README gives a deliberately short path: download the project, compile it, run it. If compilation succeeds, the application starts, generates seed data automatically, uses Sqlite as the database and exposes API documentation through Swagger. The official documentation at apk.neters.club/.doc is where the README points for getting started, configuring data and connecting a database.

The repository also ships a Dockerfile that builds and publishes inside the image. The Dockerfile uses the .NET 8.0 ASP.NET runtime and SDK images, and its comment notes that the container output port is 9291:

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
WORKDIR /app
EXPOSE 80

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY ["Directory.Build.props", "."]
COPY ["Blog.Core.Api/Blog.Core.Api.csproj", "Blog.Core.Api/"]
RUN dotnet restore "Blog.Core.Api/Blog.Core.Api.csproj"

Note the mismatch a reader will hit immediately: the Dockerfile declares EXPOSE 80 while its own comment says the container port is 9291, and the comment points you to a separate Dockerfile under the .Api layer for the build-first workflow. Treat the port as something to confirm in your own run rather than something the file settles.

For a local run, the README's instruction is to build and run the solution, then open the Swagger page. The repository root contains Blog.Core.sln, Blog.Core.Publish.bat and Blog.Core.Publish.Linux.sh for publishing, and CreateYourProject.bat plus a Blog.Core.Webapi.Template project template for regenerating the project under your own name. The README also mentions T4 templates that generate each layer's code, and a DbFirst path that creates the four-layer files from an existing database.

Where Blog.Core stops: Quartz clustering and the paid edition

The README is unusually candid about one limit: Quartz.net is used for task scheduling, but it says the current setup is single-machine multi-task and cluster scheduling is not supported. If your job runner has to survive a node failure or avoid duplicate execution across replicas, this framework does not give you that out of the box. You would be adding the clustering yourself.

The larger boundary is the commercial edition. The README separates an enterprise paid version from the open source one and lists what it adds: all primary keys changed to string type (snowflake by default, GUID supported), department data permissions driven by configurable strategies, a permission handler that fixes permission desynchronization across distributed instances, online-user viewing with forced logout, user blacklists, and a positions feature. Several of those items are marked as requiring Redis. In other words, the distributed permission story is a paid feature, not an open source one, and anyone planning multiple API instances should read that list before assuming parity.

Two smaller caveats. The README says the official documentation is still being organized, so expect gaps. And the repository's own badges disagree with each other: the SDK badge reads 6.0.1 and the README headline says .NET Core 6.0, while the Dockerfile targets 8.0 images and the repository description says ASP.NET Core 8.0. Check the .csproj target framework rather than the badge.

Blog.Core against a plain ASP.NET Core Web API template

The honest alternative is the built-in ASP.NET Core Web API template plus the pieces you choose yourself: ASP.NET Core Identity or a JWT handler for authentication, EF Core or Dapper for data access, Serilog for logging, and your own permission tables. That path gives you full control of the dependency graph and no framework conventions to fight.

The difference in approach is what you get on day one. The plain template gives you one controller and an empty Program.cs; you decide the layering. Blog.Core gives you eight named layers, a generic repository over SqlSugar, four AOP aspects, button-level RBAC, seed data and Swagger, and asks you to delete what you do not want. If your team already has opinions about layering, the second path is less work. If your team has no opinions and needs a shape, Blog.Core's shape is the product.

A second comparison worth naming is the ORM choice. SqlSugar is the data layer here, not EF Core, and the README leans on that: multi-database switching, configurable primary key types, split-table demos and DbFirst generation are SqlSugar capabilities. If your team's existing code and migrations are EF Core, adopting Blog.Core means either running two data stacks or porting.

Maintenance, upgrades and what the Apache-2.0 licence leaves you

The last push to the default branch was on 2026-04-16, and the repository is not archived. That is roughly five months before the date of writing, so the project is not dormant, but the repository shows no releases at all, which means there is no tagged version to pin and no changelog to read before you upgrade. Upgrades therefore mean diffing the master branch against your fork, and since Blog.Core is a template you edit rather than a dependency, every upstream change is a merge you perform by hand. Budget for that: a scaffold that you have modified heavily becomes expensive to re-sync, and the README's own advice (delete the layers you do not need) makes the divergence larger, not smaller.

The licence is Apache-2.0, and the LICENSE file sits in the repository root. Apache-2.0 is a permissive licence that includes an explicit patent grant and requires you to keep the licence and notice files when you redistribute. That is the open source side. The commercial edition described in the README is a separate arrangement with its own terms, and the README states that contributors to those paid features can obtain a commercial licence at half price. Do not read the Apache-2.0 file as covering the paid edition; the two are distinct, and the README is the place that says so. This is a description of what the documents state, not legal advice.

Editorial conclusion

Adopt Blog.Core if you are starting a .NET 8 API and want RBAC, JWT, a repository layer and seed data already wired together, and you accept that the codebase is a template to edit rather than a package to depend on. Do not adopt it if you need cluster-wide Quartz scheduling, or if you want the commercial features (string primary keys, distributed permission sync, online-user kick-out, blacklists, positions) that the README places in the paid edition. Before committing, run the Sqlite startup once, then verify your target database is on the supported list, and read the Apache-2.0 LICENSE file in the repository root.

Frequently asked questions

Official sources

1. anjoy8/Blog.Core on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README