EventEase

EventEase is an event management application built with ASP.NET Core Blazor. It provides an interactive event listing, event details, and registration experience.

Project context

EventEase is a course project for Blazor for Front-End Development. It is being developed to practice building interactive web applications with ASP.NET Core Blazor.

Technology

• .NET 10
• ASP.NET Core Blazor
• Interactive Server rendering
• C# with nullable reference types enabled

Prerequisites

• .NET 10 SDK

Verify the installed SDK with:

dotnet --version

Getting started

Clone the repository, change into the project directory, and run the application:

git clone <repository-url>
cd EventEase
dotnet restore
dotnet run

Open the URL shown in the terminal. To select a profile explicitly, use dotnet run --launch-profile http (HTTP on port 5245) or dotnet run --launch-profile https (HTTPS on port 7237 and HTTP on port 5245). Both checked-in profiles use the Development environment.

Build

Restore dependencies and build the project with:

dotnet build

To run the application without rebuilding:

dotnet run --no-build

Application routes

Route	Description
/	Home page
/events or /events?page=2	Browse events, 20 per page
/events/{id:int}	View event details
/registration	Create an event through the registration form
/events/{id:int}/register	Register a participant for an existing event
/attendance	My registrations and check-in
/health	Process liveness check
/not-found	Recovery page for missing pages or events
/Error	Production exception-handler page

Project structure

EventEase/
├── Components/       # Razor components, pages, layouts, and navigation
├── Models/           # Application data models
├── Services/         # Application services and event data management
├── Properties/       # Launch profiles
├── wwwroot/          # Static assets and styles
├── docs/             # Architecture, implementation, and verification notes
├── tests/            # xUnit regression tests
├── change.md         # Timestamped change history
├── EventEase.csproj   # Project definition
└── Program.cs         # Application startup and service configuration

Validation and performance

The app uses global Interactive Server rendering for binding, validation, and navigation. Event name and location are required (whitespace-only values are rejected) and limited to 200 characters. Invalid or empty dates display field validation errors and block saving. EventService also validates writes so callers cannot bypass these rules. EventCard validates all bound fields and requires a positive ID before displaying details or links; invalid data displays a fallback message.

The event list displays a responsive bordered table with a header and registered/attended totals. It reads and renders at most 20 events per page. Page links preserve browser history and can be bookmarked. Invalid page values fall back to page 1; numeric values outside the available range are clamped. Event lookups and updates use an ID index, and page reads copy only the requested slice. Shared service operations are synchronized, and returned objects are copies so unsaved edits cannot change stored events.

Missing pages, malformed event IDs, and unknown event IDs show a recovery page. Direct requests return HTTP 404; interactive navigation displays the same not-found UI.

Tests

dotnet test tests/EventEase.Tests/EventEase.Tests.csproj

Regression tests cover invalid model data, card parameter changes, generated links, HTML escaping, detached data, concurrent saves, paging through 10,000 added events, and HTTP routing with an in-memory application host. The expanded suite covers session restoration, attendee validation, concurrency, and registration failure/retry handling. See verification notes for coverage and browser checks.

Run the rendering benchmark separately:

dotnet run --project tests/EventEase.Performance/EventEase.Performance.csproj -c Release -- docs/performance-results.json

Performance measurements document the method, results, and limits. The comparison renders the full collection versus the 20-event page.

Data storage

Event data is provided by a singleton EventService and shared by users of the same app process. Changes are lost when the application stops. Separate processes do not share data, and concurrent edits to one event use last-write-wins behavior.

Participant registration and self check-in are implemented through IAttendanceService. Its demo records also live in process memory and are lost on restart. A circuit-scoped UserSessionTracker restores anonymous session identity and the latest form draft from protected browser-tab storage across navigation and refresh (12-hour default). This is session continuity, not authentication or durable attendance storage.

See Twelve-Factor review for environment configuration, production gaps, and the exact session-continuity contract.

Documentation

Additional project documentation is available in the docs directory:

• Twelve-Factor review and session contract
• High-level architecture
• Data binding
• Navigation
• Implementation steps
• Verification results
• Rendering performance measurements
• Timestamped change history

License

This project is licensed under the MIT License.