ASP.NET Core MVC and Clean Architecture Dev Notes | Great Lynx Designs

Dev Notes

ASP.NET Core MVC and Clean Architecture

This dev note explains the difference between the basic ASP.NET Core MVC pattern I learned in coursework and the more layered architecture used in a larger business application project. While the application used ASP.NET Core MVC for its web layer, the overall solution was organized into separate Core, Infrastructure, and UI projects in a way that closely resembles a Clean Architecture–style layered system.

Starting with basic ASP.NET Core MVC

In a straightforward classroom example, ASP.NET Core MVC is usually taught as a pattern for organizing a web application into three main concerns: models, views, and controllers. A browser request reaches a controller, the controller works with application data, and a Razor view renders the response back to the user as HTML.

In its simplest form, the structure often looks something like this:

Controllers/
Models/
Views/
wwwroot/
Program.cs

Basic MVC request flow

Browser Request

↓

Controller

↓

Model / Data Access

↓

Razor View

↓

HTML Response

MVC is a web application pattern. It explains how requests, views, and application data relate to one another. It does not by itself describe the full structure of a larger system.

Why the project became more complex

The business application project I worked on did use ASP.NET Core MVC, but it did not remain a simple one-project MVC app. The project grew into something more structured, with additional layers for business logic and data access. This meant the architecture extended beyond the classroom version of MVC into a more enterprise-style design.

Instead of placing most logic directly in controllers or tightly coupling the UI to the database, the application separated concerns into multiple projects. That is where the influence of Clean Architecture becomes visible.

What changed

Controllers stopped being the main home of business logic.
Services handled workflows and application rules.
Repositories handled database interactions.
The system was split into dedicated projects for UI, Core, and Infrastructure.

Recognizing the Clean Architecture influence

The project structure reflects a layered design that closely resembles Clean Architecture. In this kind of approach, business rules and domain concepts are kept more central to the system, while frameworks, databases, and delivery mechanisms remain in outer layers.

In practical terms, the project separated its concerns into three main areas:

LMLLCWebApp.Core
LMLLCWebApp.Infrastructure
LMLLCWebApp.UI

That kind of separation is a classic clue that the architecture is no longer “just MVC.” MVC still exists, but primarily in the UI layer.

Layered view of the application

UI Layer
Controllers, Views, ViewModels, Areas

↓

Infrastructure Layer
DbContext, Repositories, EF Core

↓

Core Layer
Domain, Contracts, Services, Business Rules

How MVC fit inside the larger architecture

UI layer responsibilities

Controllers/
Views/
ViewModels/
Areas/
wwwroot/

This part of the solution is where ASP.NET Core MVC clearly appears. Controllers respond to HTTP requests, prepare data for views, and return Razor-rendered pages to the browser.

Core and Infrastructure responsibilities

Core/
  Domain/
  RepositoryContracts/
  ServiceContracts/
  Services/

Infrastructure/
  DbContext/
  Repositories/

The deeper application rules and database abstractions were separated into layers outside the MVC UI. This is where the project moved beyond basic coursework patterns.

A more accurate description of the project is not “MVC instead of Clean Architecture,” but MVC inside a Clean Architecture–style layered application.

Request flow in the layered application

Once the service and repository layers are added, the application flow becomes more involved than the simple controller-model-view diagram. Controllers still receive requests, but much of the real application work happens deeper in the stack.

A simplified rendering of that flow looks like this:

Browser
  ↓
MVC Controller
  ↓
Application Service
  ↓
Repository
  ↓
Entity Framework Core
  ↓
MySQL Database

Why this layering matters

Business rules can be organized outside the UI layer.
Data access can be abstracted and tested more cleanly.
The project is easier to reason about as it grows in complexity.
The web framework becomes one layer of the system rather than the whole system.

Repository and service patterns in practice

The project also appears to use repository and service abstractions. Repository contracts define how the rest of the application asks for data, while concrete repositories in the Infrastructure layer perform the actual database work. Services then coordinate business logic using those repositories.

This means controllers likely interacted with services rather than directly placing all data logic in controller actions.

Typical interaction path

Controller
  ↓
Service
  ↓
Repository Interface
  ↓
Repository Implementation
  ↓
DbContext / EF Core / MySQL

What I learned from this architecture

One of the most useful lessons from this project is that software architecture patterns often stack together rather than replace one another. MVC remained important, but it was only one part of the application. The project introduced me to the reality that larger systems often use multiple design patterns and abstractions at once.

That also means architectural labels should be used carefully. Calling the project only “ASP.NET Core MVC” captures the UI framework, but it misses the larger layered design. Calling it only “Clean Architecture” misses the fact that the user-facing web layer still relied on MVC and Razor views.

Part of what made this project educational is that some of this architectural complexity was not part of the basic classroom MVC model I started with. Working through the codebase later helped me better understand how layered architecture, service abstractions, and repository patterns fit together in practice.

Most accurate summary

This project was an ASP.NET Core MVC web application organized using a Clean Architecture–style layered structure, with separate Core, Infrastructure, and UI projects and with service and repository abstractions supporting business logic and data access.

Conclusion

Looking back, this project makes more sense to me when viewed as a layered application rather than a simple classroom MVC exercise. ASP.NET Core MVC was still the technology used for the web layer, but the overall design expanded into something more ambitious and more reflective of larger business applications. That complexity introduced additional moving pieces, but it also exposed me to ideas that go beyond a basic CRUD tutorial: architectural layering, dependency boundaries, service logic, repository abstractions, and clearer separation of concerns.

In that sense, the project became a useful bridge between introductory ASP.NET Core MVC and the broader design patterns often used in real-world .NET software development.