Biergarten SQL Server - Architecture Overview

This solution is a monolith-oriented Web API with a layered structure. The current focus is a SQL Server-backed data layer with stored procedures and a repository-based DAL.

High-level projects

WebAPI/ - ASP.NET Core API endpoints (controllers) and application entrypoint.
BusinessLayer/ - Intended home for domain/business logic (currently minimal).
DataAccessLayer/ - Repository implementations, entities (POCOs), and SQL helpers.
DataLayer/ - Database schema, seed scripts, and data sources.
WebCrawler/ - Separate crawler executable.
DALTests/ - Data access tests.

Data access architecture

Entities (POCOs) live in DataAccessLayer/Entities/.
Repositories live in DataAccessLayer/Repositories/ and implement interfaces like IUserAccountRepository.
SQL execution lives in DataAccessLayer/Sql/.
Stored procedures for CRUD live under DataAccessLayer/Sql/crud/ and are invoked by repositories.

Example flow:

WebAPI Controller -> IUserAccountRepository -> UserAccountRepository -> stored procedure

The repositories are currently responsible for:

Opening connections using DB_CONNECTION_STRING
Executing stored procedures
Mapping result sets to POCOs

Database schema and seed

DataLayer/schema.sql contains the database schema definitions.
DataLayer/database/ holds application functions and CRUD procedures.
DataLayer/seed/ holds seed-only procedures and the SeedDB.cs entry point.
SeedDB.cs honors SEED_MODE (database, seed, or all) to control which scripts run.

Key conventions

Environment variables: DB_CONNECTION_STRING is required for DAL and seed tooling.
Stored procedures: CRUD operations use usp_* procedures.

Suggested dependency direction

WebAPI -> BusinessLayer -> DataAccessLayer -> SQL Server
                         -> DataLayer (schema/seed/scripts)

Keep business logic in BusinessLayer and avoid direct SQL or ADO code outside DataAccessLayer.

2.0 KiB Raw Blame History