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

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

What are Vertical Slices?

A quick definition of a vertical slice is a top-to-bottom, specific, self-contained feature of an application. A feature spans the applications layers 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 she makes in this feature will affect another feature. 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.

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

Vertical Slices 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 Page file structure

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

@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.