As software developers and consultants we are always on the lookout for a better way. It’s what we have been doing since the invention of computer and software programming. The pioneers of software development laid a strong foundation and throughout the years we have improved upon it.

Vertical Slice Architecture helps software developers organize their code in a robust and logical way, and Microsoft’s Razor Pages fit right into the Vertical Slice paradigm.

What is vertical slice architecture?

A quick definition of a vertical slice architecture is a top-to-bottom, specific, self-contained feature of an application. A feature that spans the layers of the application from the database to UI within its own bounds. Very little sharing of logic, if any, is had among different features. Employee management is only concerned with Employee management. It doesn’t share a service with Product management, for example.

This is different than a horizontal architecture where different features share logic between each other via the different layers and services of the software. 

In a vertical slice, developers add an entire feature from the database to the UI. This allows for faster and more confident development because the developer is only concerned with a particular feature and not bothered with how a change made in this feature will affect another. More confidence in the correctness of a feature makes it available faster for the end user.

A feature could be Todo Task management which includes adding (Create), viewing (Read), editing (Update), and removing (Delete) a Todo item. This entire feature would be self-contained in its own vertical slice architecture.

For more information see on Vertical Slice Architecture, see Jimmy Bogard’s article on the subject.

Vertical slice architecture and Razor Pages

Razor Pages is organized by, cleverly enough, Pages. A Page represents a specific, self-contained piece of an application or feature. Sound familiar? Each Page has a View and a Model coupled together. The Model contains the logic specific to that Page such as Post, Get, Edit, or Delete.

If we were creating a Todo application in Razor Pages our file structure might look like the following:

razor pages file structure

There are two files for each Page. A Page (or view) and a PageModel. For a delete feature the Page looks like this:

@page
@model WebApplication1.Pages.Todo.DeleteModel
@{
    ViewData["Title"] = "Delete";
}

<h1>Delete</h1>

The corresponding PageModel looks like:

namespace WebApplication1.Pages.Todo
{
    public class DeleteModel : PageModel
    {
        public void OnGet()
        {
		//return model for the view
        }
    }
}

Razor Pages help us to organize our code by feature. Organizing in this way helps us to think logically about our code. We are only concerned about getting a list of Todo items in the Todo/Index page. In this one page, we retrieve the Todo and pass them along to the View. We don’t concern ourselves with Deleting or Updating Todo items here. More to the point, we don’t concern ourselves with any other feature of the application. We can be confident in the stability of the application because we kept the feature coupled only within itself.

Let's Talk

Have a tech-oriented question? We'd love to talk.