ForgeFusion.Core.Data.Common 1.1.0-beta

ForgeFusion Data Layer

ForgeFusion.Core.Data

🔗 NuGet:
🛡 License: MIT
🔐 Secure First: Security analyzers enabled
🌍 Part of the cloudextend.net Initiative

ForgeFusion.Core.Data is a lightweight, extensible .NET library for building secure and scalable data access layers in modern cloud-native and distributed applications.

It is part of the ForgeFusion Framework, built to help African technologists ship software that is secure, fast, and future-ready

✨ Features

• ✅ Strongly-typed Repository Pattern using generics
• 🔐 Security-first: Integrated .NET analyzers & secure defaults
• 🔄 Async-first methods to support modern workloads
• 📦 Ready for NuGet & CI/CD pipelines
• 🌍 Built for scale in African and global digital ecosystems

📦 Installation

Install via NuGet: Enable pre-release

dotnet add package ForgeFusion.Core.Data.Common

Naming Conventions

For consistency & uniformity across the system and the database, Title Case was adopted from the get go.

• Database tables, and their related CLR model/class files, should conform to this convention.
• Foreign Keys; should be in Title Case and try to adhere to this format {PrincipalTableName}Id

Categorization & Grouping of Files

In general, the system has roughly 10 high level groups under which all data can fit into e.g. Config,MasterData,TraderEntities etc. This grouping has been used to organize project files into folders baring the name of a group. All files such as Database Models, ViewModels, and API Endpoints follow this structure. It helps in keeping things organized, comprehendable, and easy to expand when building new functionalities.

Database Migration Scripts

To run migrations, open a terminal or command prompt and make sure to navigate to the folder ../ForgeFusion.Api such that its your current/default root path on the terminal.

Bare in mind that the environment variable ASPNETCORE_ENVIRONMENT is used to determine which settings file to use for migrations. See below the different commands to run to set different values for the variable and the settings file thats used in turn.

• SET ASPNETCORE_ENVIRONMENT=Local --> appsettings.Local.json
• SET ASPNETCORE_ENVIRONMENT=Staging --> appsettings.Staging.json
• SET ASPNETCORE_ENVIRONMENT=Development --> appsettings.Development.json
• SET ASPNETCORE_ENVIRONMENT=Production --> appsettings.Production.json

Run migrations using the commands below

ForgeFusion Database

dotnet ef migrations list --context ForgeFusionDbContext --project ../ForgeFusion.Core.Data --verbose
dotnet ef migrations add {Name} --context ForgeFusionDbContext --project ../ForgeFusion.Core.Data --verbose
dotnet ef database update --context ForgeFusionDbContext --project ../ForgeFusion.Core.Data --verbose

Multitenancy

The application uses the Mixed model of multitenancy whereby in the standard version, all tenants & their data are housed in one single database and separation of data is handled at the application level. A second approach which is considered premium/enterprise, has a tenant using with a customly provisioned database that is only accessible to them.

Since the number of premium/enterprise tenants is generally regarded to be less(approx 50), they are loaded into Memory Cache on application start with their respective ID's. For each HTTP request that depends on the DbContext, a decision is made on which database to point to. If the TenantId of the calling user exists among the list of cached premium/enterprise tenants, that tenants database connection string is fetched and used when initializing the DbContext to be used for that scoped/transient request.