UISampleSpark: A Developer's Swiss Army Knife
In April 2019, the first commit established a simple CRUD reference project originally called SampleMvcCRUD. Over seven years and more than 650 commits, it evolved into UISampleSpark — a comprehensive educational platform spanning seven UI paradigms, cloud-native architecture, and AI-assisted governance.
UISampleSpark: A Developer's Swiss Army Knife
Part 1 of the UISampleSpark Series — The Foundation
The Spark of an Idea
In April 2019, I committed the first lines of code to a new GitHub repository originally called SampleMvcCRUD — later rebranded to UISampleSpark as its scope grew far beyond simple MVC CRUD operations. The initial commit was modest — a .gitignore, a .gitattributes file, and the scaffolding for an ASP.NET MVC application. Within two days, the repository had its first working CRUD walkthrough with AJAX-powered forms, navigation scaffolding, and contributor documentation.
What began as a straightforward reference project would, over the next seven years and 657 commits, evolve into something far more ambitious: a comprehensive educational platform spanning multiple UI paradigms, cloud-native architecture, constitutional governance, and AI-assisted development workflows.
But in those early days, the goal was simple: build a "Swiss Army knife" for .NET developers.
The Philosophy: Learning by Building
Every developer accumulates a personal toolkit — snippets, patterns, and reference implementations they return to again and again. UISampleSpark was designed to be exactly that: a living reference project where I could test new approaches, experiment with framework upgrades, and master the fundamental operations that every web application needs — Create, Read, Update, and Delete.
The project was never intended to be production-ready. This was a deliberate design decision that would later be formalized into the project's constitution. By intentionally omitting authentication, authorization, and other production-hardening features, the codebase maintains a razor-sharp focus on core CRUD patterns without the noise of security middleware, token management, or role-based access control obscuring the fundamental lessons.
This philosophy — educational clarity over production completeness — became one of the project's defining characteristics.
The Core Architecture: Model-View-Controller
The foundation was built on the Model-View-Controller (MVC) pattern, the architectural backbone that ASP.NET developers had relied on since Microsoft introduced ASP.NET MVC in 2009. The pattern separates an application into three distinct responsibilities:
- Model: The data layer and business logic. In UISampleSpark, this meant Employee and Department entities — simple enough to understand at a glance, complex enough to demonstrate real-world relationships like foreign keys and validation rules.
- View: The presentation layer. Razor templates rendered HTML on the server, providing a familiar starting point for developers transitioning from Web Forms or learning ASP.NET for the first time.
- Controller: The traffic cop, managing communication between the Model and the View. Controllers handled HTTP requests, invoked business logic, and decided which View to render with what data.
From the beginning, the project enforced clean separation between these layers. The Mwh.Sample.Domain project held domain models and DTOs. The Mwh.Sample.Repository project encapsulated data access behind interfaces like IEmployeeService. The Mwh.Sample.Web project contained controllers and views. This layered architecture proved invaluable as the project grew.
Realistic Data with Bogus
One of the early decisions that set UISampleSpark apart from typical tutorial projects was the adoption of the Bogus library for mock data generation. Rather than hardcoding a handful of "John Doe" and "Jane Smith" records, the project generated fresh, realistic employee data on every execution.
Bogus created employees with plausible names, ages, states, countries, and department assignments. This seemingly small choice had outsized educational value:
- Varied testing scenarios: Pagination behaved differently with 50 employees than with 500. Sorting revealed edge cases when names started with numbers or special characters.
- Realistic development experience: Working with mock data that looks real trains developers to think about data diversity, edge cases, and the kinds of inputs production systems actually receive.
- No external database required: Combined with EF Core's InMemory provider, Bogus meant developers could clone the repository and run it immediately — no SQL Server installation, no connection string configuration, no seed scripts to execute.
The Initial UI Approaches
The first months of development established three distinct approaches to building CRUD interfaces, each demonstrating different tradeoffs:
Traditional MVC Form Pages
The MvcEmployee controller implemented the classic ASP.NET MVC pattern: separate views for List, Create, Edit, and Delete operations. Each action triggered a full page reload. This approach was the simplest to understand and required minimal JavaScript. The tradeoff was user experience — every interaction meant a full round-trip to the server.
jQuery AJAX with Partial Views
The Employee controller introduced a more dynamic approach. Using jQuery and AJAX, the page loaded employee data without full page refreshes. Modal dialogs powered by Bootstrap handled Create, Edit, and Delete operations. This pattern demonstrated a middle ground: server-side rendering for the HTML fragments, but client-side orchestration for the user experience.
Single Page Application Style
The EmployeeSinglePage controller pushed further toward client-side control. Using vanilla JavaScript with DataTables, this implementation loaded all employee data via the REST API and managed the entire interface on the client side. DataTables provided built-in sorting, searching, and pagination.
The REST API Foundation
Alongside these UI approaches, the project established a RESTful API from the earliest commits. The EmployeeApiController exposed standard CRUD endpoints:
- GET /api/employee — List all employees
- GET /api/employee/{id} — Retrieve a specific employee
- POST /api/employee — Create a new employee
- PUT /api/employee/{id} — Update an existing employee
- DELETE /api/employee/{id} — Delete an employee
By late 2019, Swagger/OpenAPI integration was added, providing interactive API documentation at /swagger. This established a pattern that would prove essential as the project grew. Every new UI implementation could rely on the same backend API, making the project a true showcase of how different frontends consume identical data contracts.
Early Tooling and Infrastructure
The foundational period also established critical infrastructure:
- Azure Pipelines CI: By October 2019, automated builds ran on every commit, catching compilation errors and test failures before they reached the main branch.
- Unit Testing: The test projects were introduced early, establishing a testing culture that would grow to 240 tests with 94.1% code coverage.
- Repository Pattern: All data access flowed through interfaces (IEmployeeService, IEmployeeClient), enforcing the dependency inversion principle.
- Dependency Injection: Services were registered in the DI container and injected via constructors — no service locator anti-patterns, no static helpers, no hidden dependencies.
The Repository Structure
By the end of its foundational period, the project had established a clean structure:
Mwh.Sample.Web/ Web application (MVC + API)
Mwh.Sample.Domain/ Domain models and DTOs
Mwh.Sample.Repository/ EF Core context and service implementations
Mwh.Sample.Domain.Tests/ Unit tests for domain logic
Mwh.Sample.Repository.Tests/ Unit tests for the service layer
Mwh.Sample.Console/ Console app for seeding and demosThis separation reflected a deliberate architectural decision: domain models should never depend on web frameworks, data access should be abstracted behind interfaces, and tests should live alongside the code they validate.
Looking Ahead
The foundation laid in 2019 was solid, but UISampleSpark was far from finished. The .NET ecosystem was evolving rapidly — .NET Core 3.0 had just shipped, and the unification of the .NET platform under ".NET 5" was on the horizon. New frontend frameworks were gaining traction. Docker was becoming the standard deployment vehicle. Cloud-native patterns were emerging.
The Swiss Army knife had its first few blades. The next chapter would see it grow — not just in features, but in ambition — as the project began its journey through the annual .NET upgrade cycle, from .NET Core all the way to .NET 10.
Additional Resources
UISampleSpark Series
This is part 1 of a five-part series tracing the evolution of UISampleSpark from a simple CRUD tutorial to a comprehensive web UI exploration platform.
- A Developer's Swiss Army Knife (this article) — The founding philosophy and core architecture
- Seven Years of .NET Modernization — Navigating the annual .NET upgrade cycle
- Constitution-Driven Development — How governance and AI transformed project quality
- Seven UI Paradigms, One Backend — Comparing seven frontend approaches side by side
- Modern DevOps as a Living Reference — Containerization, CI/CD, and cloud deployment
Project Links: GitHub | Live Demo | Docker Hub


