Skip to content

Source Code

A developer's-eye view of the NKO ERP codebase: where each kind of code lives, which classes carry the weight, how the container is wired, what runs in the background, which helpers everything depends on, and the conventions the code actually follows.

Architecture answers how the system is shaped. This section answers where things are and what they are called — the orientation you need before changing a line.

Page Covers
Solution Structure The five projects, their references and build settings, the folder layout of each, and the namespaces — which do not follow the folders.
Core Classes The classes touched by almost every request: BUser, CurrentRequestData, the two permission checkers, BSign, and the B* business-class pattern.
Services & DI All 71 container registrations, their lifetimes, the five interface-backed services, and the registration bugs.
Background Jobs The four job classes across three schedulers — what triggers each, and which never fire.
Helpers NextUserHelper, ExportHelper, Utils, EmailManager, CommonConstants, Enums and the security helpers.
Coding Conventions Naming, async style, error handling, and the measured house patterns — with the numbers behind each.

Orientation in one table

Artifact Count Where
Projects 5 all net6.0
.cs files 497 149 + 131 + 183 + 33 + 1
Controller classes 44 29 Controllers/ + 10 WarehouseControllers/ + 5 NKO.Shared/Controllers/
Business classes (B* / *Handler) 44 29 core + 8 warehouse + 7 shared
Razor views 517 488 in NKO.Main, 29 embedded in NKO.Shared
Entities 161 140 core + 21 warehouse
DI registrations 71 Startup.ConfigureServices
Scheduled job classes 4 across 3 schedulers
Test projects 0 —

The shape of a change

Most work in this codebase follows the same path, because almost every screen is built the same way:

flowchart TD
    A["Controllers/ — thin action<br/>resolves the user, calls BAL, picks a view"] --> B["BAL/ or WareBAL/<br/>the actual rules"]
    B --> C["NKO.DataAccess / NKO.Warehouse.DataAccess<br/>EF Core entities, queried with LINQ"]
    A --> D["Views/ — Razor page or modal partial"]
    B --> E["Helpers/ — NextUserHelper, EmailManager,<br/>BNotification, ExportHelper"]

There is no repository layer and no service interfaces for most classes, so a change to a rule is almost always a change to one B* class. The exception is the approval workflow, which is spread across NextUserHelper (who is next) and each B* class's Set…Accepted / Set…Refused methods (what the transition does).

No automated tests

The solution contains no test project — no xUnit, NUnit or MSTest reference anywhere. Every change is verified by running the application. Tracked as R8-4 in Recommendations.