# Architecture Patterns

**Date:** 2026-03-11T11:59:39Z

## Part: MVC-Starter

### Primary Architecture Pattern

Server-rendered MVC monolith with a starter/framework hybrid structure: IIS and `public/` handle request entry, `core/` provides shared runtime and dispatch behavior, and `app/` provides project-specific extensions.

## Pattern Breakdown

- **End-to-end request path:** IIS URL Rewrite sends requests to `public/Default.asp`, routes are registered there, the router resolves controller/action/params, `core/mvc.asp` validates and dispatches, and shared layout files wrap output when `useLayout` is enabled.
- **Routing pattern:** Routes are declared centrally in `public/Default.asp` and resolved through the RouteKit router object.
- **Dispatch pattern:** `core/mvc.asp` uses validation, controller whitelisting, and dynamic execution to resolve the current controller and action.
- **Application layering:** `core/` contains reusable framework/runtime behavior, while `app/` contains project-specific controllers, views, models, and repositories.
- **Rendering pattern:** Controllers orchestrate and include `.asp` view files; shared header/footer layout files provide common page chrome.
- **Data pattern:** Data access is config-driven through `public/web.config`, with DAL libraries and generator-assisted repositories/POBOs supporting database interaction.
- **Operational tooling pattern:** Schema and scaffolding workflows are handled by standalone VBScript tools under `scripts/`.

## Architectural Implications

- This codebase is optimized around a single IIS-hosted deployable unit rather than separable services.
- Framework bootstrapping and request dispatch are centralized, so edits to `public/` entry files or `core/` runtime files have broad impact.
- Dynamic dispatch is part of the framework design, which makes naming, registration, and validation rules part of the architecture contract.
- Feature development typically extends existing seams in `app/`, `db/`, and `scripts/` rather than introducing new application subsystems.
- The architecture assumes server-side HTML rendering and config-driven runtime behavior rather than client-heavy SPA patterns.

## Brownfield Notes

- The most important architectural boundary is between the framework/runtime layer (`core/`) and the app extension layer (`app/`).
- Controller activation is not automatic; routing, include registration, and whitelist registration are all part of the runtime contract.
- Windows/IIS hosting is part of the architecture, not just deployment detail, because request flow and configuration depend on it.
- Generator scripts are part of the implementation model, not just convenience tooling.