Most ASP.NET Core MVC projects still use the classic layer-first layout: one folder for Controllers, one for Models, one for Services, one for Views. It looks tidy at first, but every feature touches four folders and five files across the project, so understanding one feature means jumping between unrelated code. Vertical Slice Architecture (VSA) inverts that. Instead of organizing by technical layer, you organize by business feature, and each feature owns everything it needs inside a single folder. This article implements that structure in ASP.NET Core MVC with .NET 10.
What Vertical Slice Architecture Means in an ASP.NET Core MVC App
A vertical slice is one end-to-end feature. In MVC terms, a Currency feature is a slice that contains the controller that receives HTTP requests, the CQRS handlers that read and write data, the endpoint definitions, the validators, and the Razor views plus their JavaScript. Everything that belongs to Currency sits under one folder, for example Areas/Admin/Currency/.
Contrast that with the layered approach: a CreateCurrency change touches Controllers/, Services/, Repositories/, Models/, and Views/. Reading the feature requires assembling five locations in your head. With VSA, you open one folder and the whole feature is in front of you. The web framework stays the same — this is still classic ASP.NET Core MVC with Razor views — only the organization changes.
The Feature Folder Structure of an MVC Slice
A concrete slice structure used in production MVC applications looks like this:
Areas/Admin/Currency/
├── Controllers/CurrencyController.cs
├── Cqrs/
│ ├── GetCurrencyListHandler.cs
│ ├── CreateCurrencyHandler.cs
│ ├── UpdateCurrencyHandler.cs
│ └── DeleteCurrencyHandler.cs
├── Endpoints/CurrencyEndpoint.cs
└── Views/
├── Index.cshtml + Index.cshtml.js
├── Create.cshtml + Create.cshtml.js
├── Edit.cshtml + Edit.cshtml.js
└── Detail.cshtml + Detail.cshtml.jsControllers expose the classic MVC routes and render Razor views. CQRS handlers contain the actual read and write logic. The Endpoints folder maps the same operations to REST endpoints for API clients, and the Views folder keeps each page next to its small .cshtml.js enhancement script. Add a feature and you add one folder; delete a feature and you delete one folder.
Controller, CQRS Handler, and Endpoint in One Slice
The controller delegates to a CQRS handler. Commands handle writes, queries handle reads, and the separation is explicit without adding a message bus:
public class CurrencyController : Controller
{
private readonly IMediator _mediator; // or a direct handler factory
[HttpGet]
public async Task<IActionResult> Index([FromQuery] int page = 1)
{
var result = await _mediator.Send(new GetCurrencyListQuery { Page = page });
return View(result);
}
[HttpPost]
public async Task<IActionResult> Create(CreateCurrencyCommand command)
{
await _mediator.Send(command);
return RedirectToAction(nameof(Index));
}
}The CreateCurrencyCommand and GetCurrencyListQuery live in the same Currency folder. Whether you route through MediatR or call a handler class directly, the slice boundary stays identical — all the code for the feature is in one place, and the MVC controller stays thin. This is exactly the pattern shipped in the MVC EDevKit Basic source code, where every admin feature follows the same shape.
Razor Views with DataTables: Interactive MVC Without an SPA
One objection to MVC is that it feels less interactive than Blazor or a JavaScript SPA. The answer in production MVC apps is DataTables. The list view renders a table, and the small Index.cshtml.js file upgrades it to a searchable, sortable, pageable grid backed by the same MVC endpoint:
$('#currencyTable').DataTable({
serverSide: true,
ajax: { url: '/Admin/Currency/List', type: 'POST' },
columns: [
{ data: 'code', title: 'Code' },
{ data: 'name', title: 'Name' },
{ data: 'rate', title: 'Rate' }
]
});No SPA, no separate front-end build, no bundler pipeline. The view model, the endpoint, and the table configuration all live inside the Currency slice, which means a developer changing the list columns edits two files in the same folder instead of coordinating a front-end and back-end codebase.
Why MVC + VSA Is a Strong Fit for AI-Assisted Development
AI tools are only as good as the context you feed them. When a feature lives in one folder, an AI assistant can be pointed at a single directory and understand the entire feature — controller, handlers, validators, views, and endpoint. You stop pasting five project paths into every prompt and start saying "generate full CRUD for Tax following the Currency slice." The result is lower token consumption, fewer hallucinations, and generated code that matches your existing conventions because it can see one real slice as a template. The AI-Ready MVC starter ships exactly this: an .ai-assisted/SKILL-SOFTWARE-ENGINEERING.md skill file that turns one prompt into 18 files.
Key Takeaways
- Vertical Slice Architecture organizes ASP.NET Core MVC by business feature, not by technical layer
- Each slice holds its controller, CQRS handlers, endpoints, validators, and Razor views in one folder
- DataTables adds interactivity to MVC views without a separate SPA or build pipeline
- VSA keeps AI context focused in one folder, cutting token use and improving generated code
- The MVC EDevKit Basic product implements this exact structure in real .NET 10 source code
FAQ
Can I use Vertical Slice Architecture with classic MVC controllers? Yes. VSA is about folder boundaries, not framework choice. You keep controllers and Razor views exactly as you do today; you only move them into per-feature folders.
Do I need MediatR for VSA in ASP.NET Core MVC? No. MediatR is a convenience, not a requirement. Many production MVC apps call CQRS handler classes directly from the controller and keep the same slice structure.
Does VSA work with ASP.NET Core Areas? Yes, Areas and VSA combine naturally. Each area is a feature domain, and each feature inside it is a slice folder such as Areas/Admin/Currency/.
Is Vertical Slice Architecture good for small MVC apps? Yes. The overhead is a folder convention, so even a two-feature app benefits from knowing exactly where each feature starts and ends.