asp-classic-unified-framework/docs/architecture-patterns.md

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.