# 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`.