DEV Community: Nolan Miller

May 2026

Nolan Miller — Mon, 01 Jun 2026 17:31:15 +0000

Theme of the month

Slowing down. Being present. Refactoring.

Small wins

Long overdue business logic extraction in our Events system. More to go, but feels good to get it started!
Created infrastructure to receive, queue and handle webhooks. A nice greenfield-ish project.
A GET query method that supports a filter. May seem small, but I have enjoyed working with it so much that it made the list.

Worth a read

Project Hail Mary by Andy Weir - I still haven't seen the movie, but I loved this.
The Martian by Andy Weir - Can you tell I liked Project Hail Mary?
Ten minutes a day - The reason you're even reading this post.

Half-baked

Fix more than they ask for when a bug is reported. Fix the bug for them, fix the system for you.
It's satisfying to make a flexible interface, but hopefully it's useful too
DB retrievals with filters just feel better... maybe because it makes me feel clever for putting it together.

Other Things

I'm better at golf when I'm present, and focused on the shot not the swing.

Reading is better when I'm present and focused on reading and not getting through something.

I just got a Kindle!

Ohio weather is not good.

How I Started My Coding Journey

Nolan Miller — Mon, 01 Jun 2026 17:31:09 +0000

Just 6 months ago, I didn't really know how to code, and coding was just this thing that only really smart people did. I wasn't even pursuing it. I thought it was cool, but not cool enough to learn it. I knew some basics of HTML and CSS… enough to break a Squarespace site that is. But, nothing that would make me actually dangerous. The word "JavaScript" sent me cowering.

In December of 2024, my life was turned on its head. In the course of one weekend, I lost a job that I loved with people that I cared about in one of the most painful and difficult experiences of my life AND I got engaged to my now fiancé AND I began the search for a new career. That weekend, and the following months were the highest of highs and the lowest of lows.

While avoiding the lows at a Browns game with my brother. (woof woof). He said to me, "you should just do one of those coding boot camps." It was an offhand comment, but coming from him, a software developer for a Fortune 500 company, it meant a lot. The more I thought about it, the more I realized that it was something that I had wanted to learn for a long time, and this was my chance.

After realizing that many coding boot camps are prohibitively expensive and that the resources available online for free didn't offer any way to show my skills to potential employers, I was a little disheartened. I eventually found Codecademy's Full-Stack Developer Professional Certification course. And full transparency, I am at 50% completion of their robust and comprehensive course. (51% at the time of posting)

Paying around $250 for Codecademy (thanks, Mom), put enough skin in the game for me to motivate me to make progress through the course. I breezed through HTML and CSS and started finally pounding my head against the wall with JavaScript. I ate up the content and project for 3+ hours every day, the rest of my time dedicated to filling out job applications and checking my email for even one response. The lessons were informative and the projects inspired new ideas of things that I could now build on my own!

Am I an expert? Absolutely. Not.

Do I know what I'm doing? Eh. I'm figuring it out.

But, if you've ever thought, "Man, I wish I knew how to code." Or you've been putting off your first course, let me give you this. Here is your permission–no–your encouragement to just pick it up and do it. You don't have to be super smart, you don't have to be technically gifted, you don't have to be a math whiz, and you don't have to spend a ton of money and a ton of time to start seeing the joy, inspiration, confusion, frustration, and wonder that comes with learning how so much of our world works.

Let me take a break to tell you a very short story. I am a trombone player. I play in a couple local groups, mostly on a volunteer basis. But, there was a time that I seriously studied this. I have a Master's in trombone performance… (really helping me out now). Until recently, I maintained a small studio of high school trombone students that I taught weekly. I tried to pour out what I had learned on my journey and help them to become spectacular students. I did see a lot of improvement in their playing, but I consistently found my teaching come up short. So often, I overlooked small details or aspects of music or trombone-playing that came so naturally to me after 15 years of practice and study, I didn't think to teach it. A lot of it, I had forgotten how to even articulate!

Why am I telling you this? Because, if you're just starting to code, you're looking at a lot of resources that are incredibly intimidating and some that assume that you have lots of background knowledge. My goal with this blog is to create a resource that documents my journey as I learn to code and build projects.

You'd be surprised at the things you can learn or change in 6 months. So start today, and learn as you code!

Learn ASP.NET from Scratch

Nolan Miller — Mon, 01 Jun 2026 17:27:51 +0000

If you read my last post, you read all of the things that I'd like to learn this year, starting with ASP.NET Core. I've spent the past week gathering resources from Microsoft's documentation, blogs, forums and internet searches to create myself a 17 module learning plan.

If you're looking to get your feet wet on Microsoft's full stack web framework, then I hope these resources are helpful for you too.

FYI: This learning path assumes that you have a basic knowledge of C# syntax and a general knowledge of the available libraries. If you don't, Codecademy has a free course!

The ASP.NET Core Learning Path

Introduction to ASP.NET

1. dotnet cli

Module Goal: Be able to explain the most common commands with their options and use them throughout the development process.

Resources:

Microsoft: .NET CLI overview
Tutorials Teacher: .NET Core Command-Line Interface
Andrew Lock - ASP.NET Core in Action
- Reference - 2
- 2.2 Creating your first ASP.NET Core application - p. 32

2. ASP.NET Web Application Starting Template

Module Goal: Be able to explain the purpose and use of each of the files and folders that are generated by the starting template of an ASP.NET application.

Resources:

Tutorials Teacher: Create ASP.NET Core MVC Application
Tutorials Teacher: wwwroot Folder
Microsoft: ASP.NET Core fundamentals overview
Andrew Lock - ASP.NET Core in Action
- 2.5 The csproj project file - p. 38
- 2.6 The Program class - p. 41
- 2.7 The Startup class - p. 44

3. Dependency Injection

Module Goal: Describe the purpose of Dependency Injection and be capable of configuring dependencies within ASP.NET's Dependency Injection framework.

Resources:

Microsoft: Dependency injection in ASP.NET Core
CodeProject: Exploring the Microsoft.Extensions.DependencyInjection Machinery
StackOverflow: How can I use Microsoft.Extensions.DependencyInjection
Andrew Lock - ASP.NET Core in Action
- 10 Service configuration with dependency injection - p. 267

4. Application Configuration using CreateDefaultBuilder

Module Goal: Explain CreateDefaultBuilder's purpose and uses. Identify common configuration patterns in ASP.NET Core.

Resources:

Andrew Lock - ASP.NET Core in Action
- 11 Configuring an ASP.NET Core application - 303

Creating APIs with ASP.NET Core

5. Minimal API

Module Goal: Create an API that responds to requests with at least 4 different endpoints. Create an endpoint that returns multiple status codes based on a condition.

Resources:

Microsoft: Minimal APIs overview
Microsoft: Minimal APIs quick reference
C# Corner: Restful API In ASP.NET
Andrew Lock - ASP.NET Core in Action
- 9.1 What is a Web API and when should you use one? - 235
- 9.6 Generating a response from a model - 258

6. Connecting Your API to PostgreSQL using Entity Framework

Module Goal: Connect the fifth module's API to a PostgreSQL database using Entity Framework and create API endpoints to handle CRUD operations.

Resources:

C# Corner: Building a Robust ASP.NET Core Web API with PostreSQL
ASP.NET Boilerplate: EF Core PostreSQL Integration
SuncFusion: Creating an ASP.NET Core CRUD Web API with Dapper and PostgreSQL
Andrew Lock - ASP.NET Core in Action
- 12.4 Querying data from and saving data to the database - 355

6a. Connect to PostgreSQL with ADO.NET

Module Goal: Branch the previous module's project and access the PostgreSQL database without using EF. Perform data calls directly on ADO.NET.

Resources:

Microsoft: ADO.NET Overview
[Microsft Q&A: ASP.NET Core Web App with SQL (No Entity Framework)](https://learn.microsoft.com/en-us/answers/questions/1123214/asp-net-core-web-app-with-sql-(no-entity-framework)
Devart: How to connect to PostgreSQL in .NET with C#

7. Controller-Based API

Module Goal: Explain the differences and cost/benefit of a Controller-Based API vs a Minimal API. Refactor your Minimal API into a Controller-Based API.

Resources:

Microsoft: Choose between controller-based APIs and minimal APIs
Microsoft: Create web APIs with ASP.NET Core
Andrew Lock - ASP.NET Core in Action
- 9.1 Creating your first Web API Controller 238
- 9.2 Applying the MVC design pattern to a Web API
- 9.4 Attribute routing: taking fine-grained control of your URLs - 246

8. Adding Built-In and Custom Middleware

Module Goal: Identify most common ASP.NET middleware and be able to explain what it is used for. Create your own middleware function and mount it to the application.

Resources:

Microsoft: ASP.NET Core Middleware
Microsoft: Write custom ASP.NET Core middleware
Microsoft: Request and response operations in ASP.NET Core
Andrew Lock - ASP.NET Core in Action
- 3 Handling requests with the middleware pipeline

The Model-View-Controller Design Pattern

9. ASP.NET MVC Starting Templates & Basic Routing

Module Goal: Create an MVC application that responds to GET and POST requests at at multiple different routes.

Resources:

Microsoft: ASP.NET Core MVC Tutorial
TutorialsTeacher: MVC Architecture
Andrew Lock - ASP.NET Core in Action
- 2.8 MVC middleware and the home controller - 52
- 4.1 An introduction to MVC - 95
- 4.2 MVC controllers and action methods 113
- 5 Mapping URLs to methods using conventional routing - 120

10. Binding Models to your Views in Razor Syntax

Module Goal: Create a Razor view from scratch. Create a model to attach to that view. Enable CRUD operations on the page model from scratch.

Resources:

Microsoft: Razor syntax reference for ASP.NET Core
Microsoft: Layout in ASP.NET Core
Microsoft: Create reusable UI using the Razor class library project in ASP.NET Core
Andrew Lock - ASP.NET Core in Action
- 7 Rendering HTML using Razor views - 175

11. Using Tag Helpers for User Input other Useful Things

Module Goal: Identify and explain the most common ASP.NET tag helpers. Handle different types of user input. Create your own custom tag helper.

Resources:

Microsoft: Tag Helpers in ASP.NET Core
Microsoft: ASP.NET Core built-in Tag Helpers
Andrew Lock - ASP.NET Core in Action
- 8 Building Forms with Tag Helpers
- 19.4 Creating a custom Razor Tag Helper 591

12. Using DataAnnotations to Validate Your Models

Module Goal: Identify and explain the most common ASP.NET DataAnnotations. Add validation to your model.

Resources:

ByteHide: Data Annotations in C#: Your Complete Guide
Microsoft: System.ComponentModel.DataAnnotations Namespace
Andrew Lock - ASP.NET Core in Action
- 6.3 Handling user input with model validation

13. Styling your view models

Module Goal: Describe common approaches to styling Views in ASP.NET Core. Implement CSS styles and connect the application to Bootstrap. Create a layout and edit its styles.

Resources:

Syncfusion: ASP.NET Core Succinctly
- Using CSS isolation - 36
Bootstrap: Get started with Bootstrap
Bootstrapdash: How to Use ASP.NET with Core Bootstrap
Infragistics: Styling Your Application

14. ASP.NET Core Identity, and Adding Authentication & Authorization

Module Goal: Using ASP.NET Core Identity, add authentication to your application. Describe the common authorization methods used by ASP.NET Core, choose one to implement into your MVC application.

Resources:

Andrew Lock - ASP.NET Core in Action
- 14.1 Introducing authentication and authorization - 402
- 14.2 What is ASP.NET Core Identity - 412
- 14.4 Adding ASP.NET Core Identity to an existing project - 423
- 14.5 Managing users: adding new claims to users - 428
- 15 Authorization: securing your application 432

Polish and Deploy Your Application

15. Add unit tests for your action methods using NUnit

Module Goal: Add tests to a controller of your ASP.NET application. Create tests that increase the confidence of the application working. Understand the basic syntax of NUnit as it relates to the form of a unit test.

Resources:

Microsoft: Unit testing C# with NUnit and .NET Core
C# Corner: Introduction to NUnit Testing Framework
testRigor: ASP.NET Testing
Andrew Lock - ASP.NET Core in Action
- 20.4 Unit testing MVC controllers

16. Publish your application with IIS Express

Module Goal: Describe the use of IIS Express and the term "publish". Explain the hosting model of ASP.NET Core. Publish your MVC application to IIS Express.

Resources:

Microsoft: Publish an ASP.NET Core app to IIS
Microsoft: Native AOT Deployment
Andrew Lock - ASP.NET Core in Action
- 16.1 Understanding the ASP.NET Core hosting model - 463
- 16.2 Publishing your app to IIS - 470

16a. Deploy your application to Linux with Nginx

Module Goal: Provision an EC2 instance of Ubuntu. Configure Nginx to serve the application on a domain and point a DNS provider to the address. Bonus points for setting up CI/CD with Github Actions.

Resources:

Microsoft: Host ASP.NET Core on Linux with Nginx
nginx: Beginner's Guide
nginx: Docs
Andrew Lock - ASP.NET Core in Action
- 16.3 Hosting an application on Linux

17. Configure Logging to Monitor your application

Module Goal: Add searchable and useful logging to the application using Microsoft-provided logging to monitor the application.

Resources:

Microsoft: Logging in .NET Core and ASP.NET Core
Dev.to: Logging in ASP.NET
Andrew Lock - ASP.NET Core in Action
- 17.1 Using logging effectively in a production app - 503
- 17.2 Adding log messages to your application - 507
- 17.5 Structured logging: creating searchable, useful logs

Build a Database Connection Framework In 133 Lines Of Code

Nolan Miller — Mon, 01 Jun 2026 17:27:44 +0000

Entity Framework is a popular database connection choice for .NET developers. It's fairly simple to use but, what if I told you that we could create a connection framework on top of ASP.NET that would allow us to get total control of the SQL that we write? The cherry on top is that it will take about as much code as it takes to configure Entity Framework.

In this article, I'll show you how to connect an ASP.NET minimal API to a local SQLite database Entity Framework. We will still map tables into classes allowing us to interact with our data in C#. I'll include every line of code you need, so let's get started.

The data

First, we have to do is set up a database. I decided to use SQLite since I've never had an excuse to before. Make sure that you have SQLite installed and that you've connected to a database. (You could also connect to a MySQL, SQL Server or Postgres database using the following method too, but this article will focus on SQLite.)

With our database, we'll track student information and grades. First, connect to SQLite and create a database, we'll call it Students.db, then create a students table and a grades table.

sqlite3 Students.db

sqlite> CREATE TABLE students (
...>        id INTEGER PRIMARY KEY,
...>        name TEXT,
...>        school TEXT
...> );
sqlite> CREATE TABLE grades (
...>        id INTEGER PRIMARY KEY,
...>        scored INTEGER,
...>        out_of INTEGER,
...>        student_id INTEGER,
...>        FOREIGN KEY (student_id) REFERENCES students(id)
...> );

Drop these two table definitions into ChatGPT and have it script you out some sample data for both of the tables. This isn't necessary, but it will make your API more interesting to work with once we're done. Once you've done that, we're ready to get started.

The connection

Instead of using Entity Framework, we'll remove that layer of abstraction to use ADO.NET. These are the libraries that EF uses in its implementation. Microsoft was kind enough to wrap them up in a NuGet package for us. In the root of your project, run the following command:

dotnet add package Microsoft.Data.Sqlite

With that installed, we can work on getting our application connected to the database. First, grab your connection string. Each database provider has their own format for these, but I'll trust that you can find that and configure it on your own. Sqlite's format is below:

"Data Source=path/to/database_file.db"

The best way to give your application access to this is through a configuration object that you supply through dependency injection. I wrote an article about how to get that set up if you need help. Or you can decide to be a lawless cowboy and hard-code it... I'm not your mother.

It's finally time to write some code. In order to interact with our database, we need a class and a matching interface that will provide the connection to the rest of our application. We will call it, somewhat unimaginatively, DatabaseConnectionProvider.

// DatabaseConnectionProvider.cs
using Microsoft.Data.Sqlite;

namespace Students.Repository.SQL;

public class DatabaseConnectionProvider : IDatabaseConnectionProvider
{
    private readonly string _connectionString;

    public DatabaseConnectionProvider(IConfiguration config)
    {
        // Don't you hard code it, cowboy...
        _connectionString = config["ConnectionString"]!;
        if (string.IsNullOrEmpty(_connectionString))
        {
            throw new InvalidOperationException("Connection string not found.");
        }
    }
}

Since we'll be injecting this provider into other classes later, we'll create an interface and include a preview of the first method that we will create!

// IDatabaseConnectionProvider.cs
namespace Students.Abstractions;

public interface IDatabaseConnectionProvider
{
    List<T> GetRecords<T>();
}

Now back in our provider class, create the database connection inside this GetRecords method.

// DatabaseConnectionProvider.cs 
// after DatabaseConnectionProvider(IConfigration)

    public List<T> GetRecords()
    {
        using (var connection = new SqliteConnection(_connectionString))
        {
            connection.Open();
            var command = connection.CreateCommand();
            command.CommandText = "SELECT * FROM students;";

            var reader = command.ExecuteReader();
            while (reader.Read())
            {
                Console.WriteLine(reader["name"].ToString())
            }
            connection.Close();
            return new List<T>();
        }
    }

The SqliteConnection class is provided to us by that NuGet package that we installed earlier. This gives us the building blocks of database interaction: connection, issuing commands, and reading the results.

This isn't our final GetRecords implementation, but it will work and you can test that (if you seeded some sample values into your database). When you run it, the method creates Sqlite database connection and issues a SELECT * command to return all the students. We get back a DataReader, also provided by the NuGet package from earlier, that we can use to read the "name" column of each row before disposing the connection.

We're connected! Take a moment to celebrate.

The models

Now that we can get the data out of the database, we have a bit of grunt work to do in order to be able to work with it. For each of our database tables that creates a record we want to use in our code, we need to create a model in C# using a class.

In this small sample project, we just need two.

// Student.cs
public class Student
{
    public int Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public string School { get; set; } = string.Empty;
}

// Grade.cs
public class Grade
{
    public int Id { get; set; }
    public int Scored { get; set; }
    public int OutOf { get; set; }
    public int StudentId { get; set; }
}

One of these models represents a single row in a table. Right now, they are sad and empty. Okay, maybe not sad, but definitely empty. But, now we have a problem. How do we get a DataReader to spit out these models that we just created?

Once we get into our read loop, we could access all of the columns by name and manually assign them to the model properties. That would work, but we would have to rename our method to GetStudentRecords, since attempting to query for grades would throw an exception when looking for the "name" or the "school" columns.

Well, then we could create a new GetGradeRecords, but then, of course, we would be rewriting all of the logic inside our original method except for where we construct and return a model.

Instead, we need to offload the parsing responsibility from our DatabaseConnectionProvider. Instead of making our provider responsible for reading data, we can make each model responsible for knowing how to construct itself by giving each one Parse method.

// In Student.cs 
    public string School { get; set; } = string.Empty;

    public Student Parse(IDataReader reader)
    {
        Id = reader.ParseInt("id");
        Name = reader.ParseString("name");
        School = reader.ParseString("school");

        return this;
    }
}

// In Grade.cs
    public int StudentId { get; set; }

    public Grade Parse(IDataReader reader)
    {
        Id = reader.ParseInt("id");
        Scored = reader.ParseInt("scored");
        OutOf = reader.ParseInt("out_of");
        StudentId = reader.ParseInt("student_id");

        return this;
    }
}

If you're typing along, you probably noticed that ParseInt and ParseString are red. In order to clean up the syntax a bit, I added a couple static extensions methods on the DataReader class. You can add those in a new file.

using System.Data;

namespace Students.Repository.SQL;

public static class ReaderExtensions()
{
    public static int ParseInt(this IDataReader reader, string columnName)
    {
        return reader.GetInt32(reader.GetOrdinal(columnName));
    }

    public static string ParseString(this IDataReader reader, string columnName)
    {
        return reader.GetString(reader.GetOrdinal(columnName));
    }
}

Now all we have to do is let the DatabaseConnectionProvider know that our models have this parse method. We will do this with generics, but we are also going to need to define an interface to expose this method generically...

// ISqlDataParser.cs
using System.Data;

namespace Students.Abstractions;

public interface ISqlDataParser<T>
{
    T Parse(IDataReader reader);
}

... and make sure that our models are inheriting it.

// Student.cs
public class Student : ISqlDataParser<Student>

// Grade.cs
public class Grade : ISqlDataParser<Grade>

Now, let's update our GetRecords declaration to finish making our Parse methods available.

// In DatabaseConnectionProvider
// Replace public List<T> GetRecords()
public List<T> GetRecords() where T : ISqlDataParser<T>, new()

What this says, is that we can only call GetRecords<T> if the type that we insert for T implements the ISqlDataParser interface and has a parameter-less constructor.

Now that we can safely access Parse we can use it in GetRecords<T>.

// In DatabaseConnectionProvider.cs
// In GetRecords<T>
// Replace everything after:  var reader = command.ExecuteReader();

        var returnList = new List<T>();
        using (var reader = command.ExecuteReader())
        {
            while (reader.Read())
            {
                returnList.Add(new T().Parse(reader));
            }
        }
        connection.Close();
        return returnList;
    }
}

The query

Right now, we're in an interesting state. The GetRecords method is able to parse theoretically infinite data types, but it never will. Why? Because we've hard-coded a query into the command object that we're sending to the database.

Similar to what we did with the Parse method, we need to take away the DatabaseConnectionProvider's responsibility to choose the query it should run. That means that we're going to have to move the query up into a parameter, but, we run into a problem there.

If only add a string parameter to the method, but then we don't have access to the Command object.

So what?

The Command object is where we add SqlParameters. The only option that we would have at this point would be to use string interpolation to add the values in manually. Forcing users of our provider to build queries this way is not only poor etiquette, it is also a potential security vulnerability. Microsoft has already (hopefully), done a lot of work to secure this Command object against SQL injection attacks. No matter the sanitation that we do, adding the parameters to the correct property on the Command object is the smartest way forward.

In order to keep our provider's methods modular, we need to abstract this into a class that could be used in conjunction with any model that we create. It will wrap up our intended query with placeholders for parameter values, and a dictionary of our parameters. We'll call it DataCallSettings (naming is hard).

// DataCallSettings.cs
namespace Students.Models;

public class DataCallSettings
{
    public string SqlCommand { get; set; }
    public Dictionary<string, object> Parameters { get; set; } = new();

    public DataCallSettings(string command)
    {
        SqlCommand = command;
    }

    public void AddParameter(string name, object value)
    {
        Parameters[name] = value;
    }

}

This class is now the only parameter to GetRecords<T>. This is a significantly better developer experience than passing in positional parameters. This is a simple implementation, but if we ever decided to extend it to include support for stored procedures, retry logic, transactions or caching, we can do that without breaking our existing codebase.

Take a look at the finished method with all of the changes that we made.

// In DatabaseConnectionProvider.cs

public List<T> GetRecords<T>(DataCallSettings dcs) where T : ISqlDataParser<T>, new()
{
    using (var connection = new SqliteConnection(_connectionString))
    {
        connection.Open();
        var command = connection.CreateCommand();
        command.CommandText = dcs.SqlCommand;

        foreach (var key in dcs.Parameters.Keys)
        {
            command.Parameters.AddWithValue(key, dcs.Parameters[key]);
        }

        var returnList = new List<T>();
        using (var reader = command.ExecuteReader())
        {
            while (reader.Read())
            {
                returnList.Add(new T().Parse(reader));
            }
        }
        connection.Close();

        return returnList;
    }
}

As a bonus, I'll also give you two lines of code that will let us get single records using all the hard work we did earlier.

public T GetRecord<T>(DataCallSettings dcs) where T : ISqlDataParser<T>, new()
=> GetRecords<T>(dcs).FirstOrDefault() ?? new();

The command

Sometimes you will want to issue a query to the database that won't return anything. So, our database interface isn't quite complete. We need to build a method that allows us to send database queries without creating an empty model at the end. It will look very similar to our GetRecords method, but we will use the .ExecuteNonQuery() method instead, and we'll call it Execute. Creative... I know.

// In DatabaseConnectionProvider.cs
// After GetRecord<T>

public int Execute(DataCallSettings dcs)
{
    using (var connection = new SqliteConnection(_connectionString))
    {
        connection.Open();
        var command = connection.CreateCommand();
        command.CommandText = dcs.SqlCommand;

        foreach (var key in dcs.Parameters.Keys)
        {
            command.Parameters.AddWithValue(key, dcs.Parameters[key]);
        }

        var result = command.ExecuteNonQuery();
        connection.Close();
        return result;
    }
}

This is fine, but we're duplicating some logic between GetRecords and Execute. Let's lift it into a fancy new BuildCommand method.

// In DatabaseConnectionProvider.cs
// After Execute()

private SqliteCommand BuildCommand(DataCallSettings dcs, SqliteConnection connection)
{
    var command = connection.CreateCommand();
    command.CommandText = dcs.SqlCommand;

    foreach (var key in dcs.Parameters.Keys)
    {
        command.Parameters.AddWithValue(key, dcs.Parameters[key]);
    }

    return command;
}

And refactor both methods to use it.

// In DatabaseConnectionProvider.cs

// In GetRecords<T>
    connection.Open();
    var command = BuildCommand(dcs, connection);

    var returnList = new List<T>();

// In Execute()
    connection.Open();
    var command = BuildCommand(dcs, connection);

    var result = command.ExecuteNonQuery();

Ah, much better. But, we're not done yet. Let's add one more method that we will wind up using a lot in practice. When we perform an INSERT, the database will set the identity column, so let's make sure that we get that back out.

// In DatabaseConnectionProvider.cs
// Below Execute()

public int ExecuteWithIdentity(DataCallSettings dcs)
{
    if (!dcs.SqlCommand.StartsWith("INSERT"))
    {
        throw new InvalidOperationException();
    }

    using (var connection = new SqliteConnection(_connectionString))
    {
        connection.Open();
        dcs.SqlCommand = $"{dcs.SqlCommand} SELECT last_insert_rowid();";
        var command = BuildCommand(dcs, connection);

        var identity = Convert.ToInt32(command.ExecuteScalar());
        connection.Close();
        return identity;
    }
}

And with that... drumroll please.

We've done it! We've created, by hand, an way to interact with a database that is extensible and easy to use.

The repository

Now that we're done creating this database interface, I want to quickly walk through how you can use it. One design pattern that I use daily is the repository design pattern. This is a fancy (and admittedly somewhat confusing) name that we can give to a file that wraps up our data transfer logic, keeping our modules less coupled.

Adding a separate layer allows us to ignore the database's implementation details when we finally want to send this data to a front end somewhere. So, let's create a StudentsRepository.

// StudentsRepository.cs
using Students.Abstractions;
using Students.Models;

namespace Students.Repository.SQL;

public class StudentsRepository : IStudentsRepository
{

}

And here's the interface, complete with the methods that we're going to create.

using Students.Models;

namespace Students.Abstractions;

public interface IStudentsRepository
{
    Student GetStudent(int id);
    List<Student> GetStudents();
    int SaveStudent(Student student);
    bool DeleteStudent(int id);
}

Then, back in our repository, we will inject our DatabaseConnectionProvider. Make sure that it's registered in your Program.cs file first though. Here's an article that walks through DI in ASP.NET if you need some help with that.

Finishing the implementation now is as simple as calling the appropriate provider method with a DataCallSettings instance with a SQL query. Instead of walking through step by step, I'll just include the whole file below, so that you can see how it will look.

// in StudentsRepository.cs

public class StudentsRepository : IStudentsRepository
{
    private readonly IDatabaseConnectionProvider _provider;

    StudentsRepository(IDatabaseConnectionProvider provider)
    {
        _provider = provider;
    }

    public Student GetStudent(int id)
    {
        var dcs = new DataCallSettings("SELECT * FROM students WHERE Id = @Id;");
        dcs.AddParameter("Id", id);
        return _provider.GetRecord<Student>(dcs);
    }

    public List<Student> GetStudents()
    {
        var dcs = new DataCallSettings("SELECT * FROM students;");
        return _provider.GetRecords<Student>(dcs);
    }

    public int SaveStudent(Student student)
        => student.Id == 0 // new student
            ? InsertStudent(student)
            : UpdateStudent(student);

    private int InsertStudent(Student student)
    {
        var dcs = new DataCallSettings("INSERT INTO students (name, school) VALUES (@Name, @School);");
        AddStudentParameters(dcs, student);
        return _provider.ExecuteWithIdentity(dcs);
    }

    private int UpdateStudent(Student student)
    {
        var dcs = new DataCallSettings("UPDATE students SET name = @Name, school = @School WHERE id = @Id;");
        dcs.AddParameter("Id", student.Id);
        AddStudentParameters(dcs, student);
        return _provider.Execute(dcs) > 0
            ? student.Id
            : 0;
    }

    public bool DeleteStudent(int id)
    {
        var dcs = new DataCallSettings("DELETE FROM students WHERE id = @Id");
        dcs.AddParameter("Id", id);
        return _provider.Execute(dcs) > 0;
    }

    private void AddStudentParameters(DataCallSettings dcs, Student student)
    {
        if (student.IsNew) { dcs.AddParameter("Id", student.Id); }
        dcs.AddParameter("Name", student.Name);
        dcs.AddParameter("School", student.School);
    }
}

The conclusion

Okay, I'll admit that this more code than you probably need if you were using Entity Framework. But... it's not that much more. I find myself far more comfortable working in an application that has this level of transparency and flexibility than one that does mapping magic. To me, this is an easy trade-off.

This implementation isn't clever, it's not complicated, and it's easy to work with, even if it takes a little bit of getting used to. Over the past two years I've been programming, a significant percentage of bugs I deal with are caused by data being malformed. Maybe this is skill issues, but it has made me slightly paranoid about data handling in apps that I work on.

Using this pattern, it's being handled completely by me. If there's a problem, I know that it was something I wrote (read: something I can fix). I created the database, I wrote the SQL queries. Since I am responsible for this system, I want to know how it's handling my data.

This isn't to say that ORMs are bad. I might not be very good at working with them (see my reference to skill issues above). But, if you've never tried to use ADO.NET, I hope you feel that you have the tools to get started.

April 2026

Nolan Miller — Mon, 04 May 2026 12:18:17 +0000

Theme of the month

Slowing down, improving my craft, accomplishing more.

Where my time went

Shipped an automated accounting posting issue and spent more time intentionally learning how to abstract complex logic in a way that I like and is easy to maintain.

Small wins

I'm actually using OpenCode. Our team had a meeting this month that gave me some permission and time to explore the value of "agentic engineering." The biggest win are the small dev environment tools that I have to work with now.

Settling into a flow of how to manage development work without feeling frenzied. As someone who always needs a productivity plan, this is huge for me.

I'm getting an office at work!

Worth a read

Against Taste — capital, engineering and an orientation toward the divine
Refactoring Guru — practical, and still worth learning
We've Seen This Movie Before — is AI just Unity all over again?

Half-baked

Working on fewer things leads to greater outcomes.
Sleep, diet and exercise are the best design patterns for your life, in that order.

Other Things

I've been enjoying reading physical books. It turns out that guilting yourself into reading doesn't work, but reading things that you might enjoy reading when you feel the urge to read does.

Fingers crossed to land a house this month. I feel good that it's going to happen.

Ohio weather is not good.

March 2026

Nolan Miller — Wed, 01 Apr 2026 16:51:47 +0000

Theme of the month: Endings. My wife and I sold our house in order to move and I wrapped up a big project at work so that I can tackle some accounting integrations.

Where My Time Went

I finished a big lift and shift project of over 20 years of sales data between database servers. It was one of the smoother projects that I've done so far. Not no bugs, but fewer! The difference was becoming obsessed with proving what I'm shipping which revealed a lot of incorrect assumptions that saved me in this project.

Small Wins

With fzf and tmux, I dramatically improved my ability to navigate my system on the command line and store windows associated with projects that I'm working on. Heavily inspired by tmux-sessionizer

Before some stakeholders were about to show off a feature I had worked on to the whole staff, it started hard failing. Under pressure, I was able to locate and fix the bug in about 5 minutes!

Worth A Read

Your job is to deliver code you have proven to work — reign it in, cowboy
AI makes you boring — creative ideas are born out of painful problem solving
What God Thinks About You — a 10 year old article that I am going to return to

Half-Baked

Vertical Slice Architecture is the best strategy for agentic workflows.
TestContainers for integration testing gives me way more peace of mind than the three unit tests that I added in 20 minutes.

Other Things

I shot a 116 on 18 and then a 50 on 9 in back to back days. If I can keep this level of improvement up, I'll be on the tour by July.

Started playing Fallout 4 finally. It turns out, I am not very good at role playing games. After about 7 hours of gameplay I found myself high-tailing it out of the castle with a .38 rifle with no armor and no ammo. I have not started farming food yet.

Thoughts After a Year of Software Development

Nolan Miller — Tue, 13 Jan 2026 12:41:32 +0000

After teaching myself to code, I landed a job a year ago in December. In no particular order, here is an assorted collection of thoughts, opinions, and tidbits that I've accumulated over the past year.

Typing speed and accuracy are important

As a junior, I do not spend "most of my time thinking." Many of the problems that I need to solve aren't very mentally taxing, they just need implemented. When I started training my typing speed and accuracy by bouncing between keybr and monkeytype, even repetitive "hammer-it-out" coding sessions became much more enjoyable (and shorter too). My backspace key appreciates the rest.

AI hype is mostly just that

When an application is even remotely complex, or the context needed to solve an issue is of any reasonable size, AI is practically useless. No, I'm not going to type up my organization's application and server architecture so that I can argue with AI to get it to stop hallucinating. AI can make "nice" looking websites and decent interactivity. I really use it to search for Microsoft documentation... which is abysmal. AI is pretty good at that.

I hate Microsoft

Windows sucks. VS sucks. (Except for the debugger, that's pretty good.)

Knowing how to host an app is a differentiator

Surprisingly, there's a large portion of developers who have never stood up a production server on a bare VPS. I'm no expert, but it's really not too difficult. Maybe I just enjoy working on servers, but knowing how to host your apps outside of Netlify or Vercel is a good skill to have.

I'm really good at making really bad code

Did you want to filter that list using 3 helper methods across two classes with injected services? I got you.

The next day, I usually realize that this could have been done in 3 lines and everyone can magically understand what it does.

I'm not rich

I make more money than I used to. But, it seems like most development jobs aren't the "f*** you" money that YouTube would have you believe. Lucky for me, I really like coding.

I really like developing

I don't know if its the sound of the keyboard, the hacker aesthetic that you get from using a shell for everything, or the feeling catpuccin gives, but being a developer is really fun.

Shortcuts will make you feel like a god

I have not measured whether or not it speeds me up a significant degree, but it feels very good to not have to reach for my mouse to perform really common actions. It is well worth taking the time and the initial slowdown to get system shortcuts into your fingers. Did you know that on Windows, you can open and focus applications in your taskbar by using Win + the number corresponding to it's order? Getting used to navigating your computer this way will immediately make everything feel more smooth.

JavaScript is the worst

But, it's not going away. The event loop is the death of me everytime I mess with WASM in highly-interactive apps. It's evil... but, you need to know it.

OOP is OOK

I work in C#, and everything is an object no matter what. For most data-heavy problems, I can usually create a pretty solid mental model with this paradigm, but sometimes it feels like I'm just trying to fit into the paradigm when all i need is a couple util functions. I don't know the number of abstractions that I've taken the time to write and then immediately deleted because it no longer makes sense.

Quality of life features live on the back burner

It's really hard to convince anyone that your "it would be really nice if" idea is worth the time when there are new features and projects that other teams are depending on. At best, I've had a bit of time when I can shove it into the mix when I finish a project early unexpectedly. Instead of creating the "quality of life" ticket for later, just lump it in with the feature that you're working on.

Nobody knows what you do, or how long it will take

My manager is great, has lots of industry experience, knows me and my work pretty well, and he still cannot figure out how much time it will take for me to complete something. Being a developer uniquely gives you a lot of trust and autonomy over your schedule. This is a privilege and a responsibility. Some of the best engineering work time can produce no quantifiable output. Don't take advantage of this.

Assume any data you don't own is toxic

When you don't have crystal clear visibility into a data source for your application, you need to treat it like it can and will be wrong or missing every time. Use fallback values, conditional rendering, and generally assume the worst. It's probably a good idea to do this when you have the visibility too.

The code I actually use is short and isn't elegant

The code I use the most are tiny scripts that I've written for myself. If they get used a lot, they can't break. If they can't break, they need to be easy to maintain. If they need to be easy to maintain, then they need to be short, and so clear a beginner could understand them. Automation doesn't save time if it's buggy and hard to understand. That said, I don't rela

Small problems need solved too

When I'm trying to find the biggest and most exciting and most impactful problem to solve, I can't think of anything. But, when I open my eyes to small annoyances, I start to see them everywhere.

Backend is way more interesting than front end

I wasn't counting on this to be true. A year ago, I thought that my bent towards things that are artistic would have drawn me to the front end more. But, in all the projects I've worked on, it's been far more exhilarating to solve the pivotal logical issue than it was to figure out how to show it to someone.

A fast/slow dev server makes a huge difference

Have you ever worked with the Blazor dev server? Maybe I'm doing it wrong, but getting that thing to load up a large project takes forever.

Don't repeat yourself... but don't not repeat yourself

I've rewritten logic in a few places that has bitten me. You will always miss at least one update if you have to go to more than one place. But, in my zealousness I've created some abstractions that make absolutely no sense to work with. DRY is for information, not code. Each piece of information, or logic, should have one authoritative implementation. Don't push things together just because.

There's almost always a better way

... and someone else thought of it first. You don't need to be a hero and try to come up with the most clever solution to prove you know what you're doing. Ask questions to people at your disposal. Collaboration leads to better ideas and a better team.

Version control everything

Use git repos and feature branches religiously and neurotically. I can't count the number of times that I've started on a bug fix while I was in the middle of working on a small feature only to realize that I never created a new branch. Not only do I have to start over the bugfix, but often, I also broke my feature branch and have to walk backwards for a while to get it fixed.

That it....

I learned a lot in year one, and I know I still have so much further to go. I've never stepped into a career that it feels like no matter how much you learn, you've only just scratched the surface. It's overwhelming. But, it's also exciting!

Hopefully some of this advice is helpful to you! Hopefully you agree with some of it. Hopefully you disagree with some of it. For what it's worth, these are my thoughts.

For now.

How to Build an API with Controllers

Nolan Miller — Wed, 26 Nov 2025 20:26:31 +0000

I starting working in ASP.NET after minimal APIs had already been released and reached popularity. My first professional project involved moving endpoints from a .NET controller-based API to the new minimal syntex. Unfortunately for me, that meant I was not going to be able to avoid the controller-based API even though I wasn't particularly comfortable with the paradigm... or C# for that matter.

To save you the headache, I will walk through the very basics of creating a controller-based API and explain what I spent hours staring at code to figure out (after all, 20 hours of reading code can save you 20 minutes of reading documentation). We will create endpoints, accept parameters and document the routes all in the controller-based syntax.

What is a controller-based API?

The controller-based API, is... well, an API whose endpoints are is organized with controllers, as opposed to the minimal API, whose endpoints are registered directly on the WebApplication using extension like MapGet and MapPost. The pattern is actually just the MVC (model-view-controller) architecture, but with the "V" left out. Since an API doesn't typically return formatted views, it doesn't need to worry about that. But, the routing and model construction all work the same way as it would in an MVC application. Instead of a view, our controllers will return data wrapped in HTTP responses that can be used by any other application that can make HTTP requests.

Configuring an API for controllers

That's enough background, let's get started by bootstrapping an application using the dotnet cli. In a new terminal window, run the following command:

dotnet new webapi -n "TodoApi"

Once this runs, we'll have a working API, but if you'll open up Program.cs, you'll notice that we already have a minimal API endpoint registered here. With a little extra work, we'll have this converted into a controller-based API.

First, DELETE the following lines of code from Program.cs:

var summaries = new[]
{
    "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
};

app.MapGet("/weatherforecast", () =>
{
    var forecast =  Enumerable.Range(1, 5).Select(index =>
        new WeatherForecast
        (
            DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
            Random.Shared.Next(-20, 55),
            summaries[Random.Shared.Next(summaries.Length)]
        ))
        .ToArray();
    return forecast;
})
.WithName("GetWeatherForecast");

// leave in app.Run();

var summaries = new[]
{
    "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
};

app.MapGet("/weatherforecast", () =>
{
    var forecast =  Enumerable.Range(1, 5).Select(index =>
        new WeatherForecast
        (
            DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
            Random.Shared.Next(-20, 55),
            summaries[Random.Shared.Next(summaries.Length)]
        ))
        .ToArray();
    return forecast;
})
.WithName("GetWeatherForecast");

///////////////////////////
// do not delete app.Run();
///////////////////////////

record WeatherForecast(DateOnly Date, int TemperatureC, string? Summary)
{
    public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
}

Now, replace var app = builder.Build(), with the following:

builder.Services.AddControllers();
var app = builder.Build();
app.MapControllers();

This small bit of code here enables the use of controllers in our web app. With the AddControllers() extension method, we're registering all the services that we might need for API development in ASP.NET. Once the services are registered and the app is built, instead of manually configuring all of our endpoints, .MapControllers() goes to look at all of our Controllers and turn the action methods into route endpoints!

Creating routes from actions

Now that our Program.cs file expects to search our app for controllers, we should go and make one. To support the quintessential "todo" app with our API, in the root of the project, create a folder called Controllers. Inside that folder, make a new file called TodoController.cs and add the following code:

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;

namespace TodoApi.Controllers
{
    [Route("api/[controller]")]
    [ApiController]
    public class TodoController : ControllerBase
    {
    }
}

This is the controller that we will use to create endpoints for our API. This controller is just a C# class that inherits from the ControllerBase class that is provided by the Microsoft.AspNetCore.Mvc package. That base class gives us access to some helper methods that we will use later. We also have to include the [ApiController] attribute to tell the framework that we are creating a controller.

If we started our application now, the controller would be registered, but no routes would be added because we haven't added any action methods. So, let's do that right now. In order to add the endpoint, create a method on the controller that returns an ActionResult. Add the following method to the TodoController class.

// in TodoController
public ActionResult Health()
{
    return Ok("Healthy");
}

This is called an action method. It returns a controller action using the Ok() helper method provided by ControllerBase which returns an ActionResult that has a 200 status code and contains the string passed to it. If we build and run our application now, we have a new endpoint! Now let's talk about where we can find it when we're trying to call the API.

URL Routing in Controllers

ASP.NET does most of the routing for us when we are using controller-based syntax. If you're familiar with the MVC pattern, then you already know how this will work. Each endpoint is created using the name of the controller class, the name of the action method and optional input parameters.

The action method that we just created was inside of the TodoController and it's method name is Health. By default, to hit this endpoint, we have to send a GET request to /Todo/Health.

TodoController → Todo
ActionResult Health() → Health

Seems simple enough, but if you try this on your API now, you'll notice that you get back a 404. Sorry! I tricked you.

This controller isn't using the default routing scheme. If you've been following along with the code I've told you to put in, then you might have noticed, that we added:

[Route("/api/[controller]")]

... to the top of the controller.

This is an attribute that we can assign to a class or action method to tell the framework what pattern we want it to use when assigning an endpoint. The pattern syntax is dead simple, it will:

match any string that you pass literally,
statically replace wildcards passed between [], and
pass named parameters to action methods between {}.

The default pattern for a controller in ASP.NET is "/[controller]", where the wildcard controller is replaced by the name of the controller class with the word "Controller" stripped out.

With our custom Route attribute, we're using "/api/[controller]". So, to hit our controller endpoints, we would just have to use the base /api/Todo.

We didn't add a custom Route parameter to our Action method, so it will route using the default pattern "/[action]", where the wildcard action will be replaced with the name of the action method. If you're following from above, that makes the full pattern for our endpoint "/api/[controller]/[action]". So, to check the health of our API, get a GET request to /api/Todo/Health.

With the Route parameter, we can change the routes to whatever we would like. Let's illustrate this by adding another endpoint to this API.

[Route("/api/[controller]")]
public class TodoController : ControllerBase
{
    public ActionResult GetTodo(int id)
    {
        return Ok(id);
    }
}

Since we didn't add a Route parameter to this action method, we have inherited the default. So, to hit this endpoint in it's current state we would send a GET request to /api/Todo/GetTodo/23. This would return an action result that would presumably return a Todo that had the ID of 23. So, how is this 23 passed into the id parameter of the action method?

There is one more section of the default route pattern for ASP.NET.

/[controller]/[action]/[id]

That means that without adding a custom attribute, we have access to an id input parameter that can be submitted as a URL parameter by a user. In order to accept it all we have to do is add the parameter to the action method with the name id.

This method seems like a good candidate for customization though. Sending a GET request to an endpoint containing GetTodo seems redundant and sloppy. So, let's use the Route attribute to create our own pattern. While we're at it, our users likely know that they're hitting an API, and we don't have anything else hosted at this address, so we can adjust that too.

[Route("todos")]
public class TodosController : ControllerBase
{
    [Route("{id}")]
    public ActionResult GetTodo(int id)
}

By combining these two Route attributes, we've created a new pattern: /todos/{id}. To make the same request as earlier, we would send a GET request to /todos/23. Using Route, we kept the user from having to type out the name of our implementation method, while still leaving it intact for our developer to use. I'll also note that we switched the pattern to the curly brace syntax to better identify that id is a route parameter that will be passed in the action method parameter named id.

Now that we've got the request side of things figured out, let's take a look at how to handle getting information back to the user.

Constructing responses

So far, all we've returned is Ok(). ASP.NET also provides us methods like NotFound() and StatusCode() that return different status codes. Along with these three, we have access to a long list of helper methods through the ControllerBase class to send responses to the user. Feel free to peruse them in your own time, but today, I'll just look at four.

Ok() - Returns a 200 status code. Pass any model into it as a parameter to send this back as serialized JSON.
Created() - Returns a 201 status code, indicating a successful model creation or update.
NotFound() - Returns a 404 status code. This is useful if you have a "get one" route that is passed a failed id.
StatusCode() - If you don't have time to look up the built-in method, or you find they don't have a method that satisfies your needs, you can just pass the status code as a parameter to this method to return a response with that code.

Let's use a couple of them. Here's a SaveTodo method that uses Created and NotFound.

    [Route("{id}/Save")]
    [HttpPost]
    [ProducesResponseType(201)]
    [ProducesResponseType(404)]
    public ActionResult SaveTodo([FromBody] Todo todo)
    {
        var success = _todoService.SaveTodo(todo);
        if (success)
        {
            return Created();
        }

        return NotFound();
    }

In this example, notice the decorations. We have an [HttpPost] and two [ProducesResponseType] attributes.

The SaveTodo method takes in a Todo class instance. With what we've seen so far this wouldn't be possible without creating a horribly-long URL that took in all string parameters. Not a great interface selection. So why couldn't we pass objects with our request before? By default, action methods will represent GET request endpoints. In order to pass a body to our method, we'd send a POST request and our endpoint wouldn't match anymore.

Luckily, making this change is as simple as including the attribute [HttpPost] before the method as shown in the example.

What about the [ProducesResponseType] attribute, though? While not vital, it serves two purposes. If you use OpenAPI to generate your documentation, then these attributes can be used to add helpful details about your route. And even if you don't use OpenAPI, they're a way to provide some in-code documentation for future developers. In a simple method like this, that may seem silly, but as controller methods and their logic grow, it can certainly be nice to know at a glance what the success/failure results for your endpoint are.

Conclusion

If you've only had exposure to the newer minimal API syntax, then I hope that this makes the controller-based API pattern a bit more approachable. As with many things in "approaching-legacy-status" .NET, it is fairly verbose to get to a working API, but in my next few posts, I'll be exploring some features that you'll need a controller-based API to take advantage of and hopefully give you a reason to actually use them!

Until then!

Build a Database Connection Framework In 133 Lines Of Code

Nolan Miller — Fri, 24 Oct 2025 12:13:31 +0000

The data

With our database, we'll track student information and grades. First, connect to SQLite and create a database, we'll call it Students.db, then create a students table and a grades table.

sqlite3 Students.db

sqlite> CREATE TABLE students (
...>        id INTEGER PRIMARY KEY,
...>        name TEXT,
...>        school TEXT
...> );
sqlite> CREATE TABLE grades (
...>        id INTEGER PRIMARY KEY,
...>        scored INTEGER,
...>        out_of INTEGER,
...>        student_id INTEGER,
...>        FOREIGN KEY (student_id) REFERENCES students(id)
...> );

The connection

dotnet add package Microsoft.Data.Sqlite

"Data Source=path/to/database_file.db"

// DatabaseConnectionProvider.cs
using Microsoft.Data.Sqlite;

namespace Students.Repository.SQL;

public class DatabaseConnectionProvider : IDatabaseConnectionProvider
{
    private readonly string _connectionString;

    public DatabaseConnectionProvider(IConfiguration config)
    {
        // Don't you hard code it, cowboy...
        _connectionString = config["ConnectionString"]!;
        if (string.IsNullOrEmpty(_connectionString))
        {
            throw new InvalidOperationException("Connection string not found.");
        }
    }
}

Since we'll be injecting this provider into other classes later, we'll create an interface and include a preview of the first method that we will create!

// IDatabaseConnectionProvider.cs
namespace Students.Abstractions;

public interface IDatabaseConnectionProvider
{
    List<T> GetRecords<T>();
}

Now back in our provider class, create the database connection inside this GetRecords method.

// DatabaseConnectionProvider.cs 
// after DatabaseConnectionProvider(IConfigration)

    public List<T> GetRecords()
    {
        using (var connection = new SqliteConnection(_connectionString))
        {
            connection.Open();
            var command = connection.CreateCommand();
            command.CommandText = "SELECT * FROM students;";

            var reader = command.ExecuteReader();
            while (reader.Read())
            {
                Console.WriteLine(reader["name"].ToString())
            }
            connection.Close();
            return new List<T>();
        }
    }

We're connected! Take a moment to celebrate.

The models

In this small sample project, we just need two.

// Student.cs
public class Student
{
    public int Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public string School { get; set; } = string.Empty;
}

// Grade.cs
public class Grade
{
    public int Id { get; set; }
    public int Scored { get; set; }
    public int OutOf { get; set; }
    public int StudentId { get; set; }
}

Well, then we could create a new GetGradeRecords, but then, of course, we would be rewriting all of the logic inside our original method except for where we construct and return a model.

// In Student.cs 
    public string School { get; set; } = string.Empty;

    public Student Parse(IDataReader reader)
    {
        Id = reader.ParseInt("id");
        Name = reader.ParseString("name");
        School = reader.ParseString("school");

        return this;
    }
}

// In Grade.cs
    public int StudentId { get; set; }

    public Grade Parse(IDataReader reader)
    {
        Id = reader.ParseInt("id");
        Scored = reader.ParseInt("scored");
        OutOf = reader.ParseInt("out_of");
        StudentId = reader.ParseInt("student_id");

        return this;
    }
}

using System.Data;

namespace Students.Repository.SQL;

public static class ReaderExtensions()
{
    public static int ParseInt(this IDataReader reader, string columnName)
    {
        return reader.GetInt32(reader.GetOrdinal(columnName));
    }

    public static string ParseString(this IDataReader reader, string columnName)
    {
        return reader.GetString(reader.GetOrdinal(columnName));
    }
}

// ISqlDataParser.cs
using System.Data;

namespace Students.Abstractions;

public interface ISqlDataParser<T>
{
    T Parse(IDataReader reader);
}

... and make sure that our models are inheriting it.

// Student.cs
public class Student : ISqlDataParser<Student>

// Grade.cs
public class Grade : ISqlDataParser<Grade>

Now, let's update our GetRecords declaration to finish making our Parse methods available.

// In DatabaseConnectionProvider
// Replace public List<T> GetRecords()
public List<T> GetRecords() where T : ISqlDataParser<T>, new()

What this says, is that we can only call GetRecords<T> if the type that we insert for T implements the ISqlDataParser interface and has a parameter-less constructor.

Now that we can safely access Parse we can use it in GetRecords<T>.

// In DatabaseConnectionProvider.cs
// In GetRecords<T>
// Replace everything after:  var reader = command.ExecuteReader();

        var returnList = new List<T>();
        using (var reader = command.ExecuteReader())
        {
            while (reader.Read())
            {
                returnList.Add(new T().Parse(reader));
            }
        }
        connection.Close();
        return returnList;
    }
}

The query

If only add a string parameter to the method, but then we don't have access to the Command object.

So what?

// DataCallSettings.cs
namespace Students.Models;

public class DataCallSettings
{
    public string SqlCommand { get; set; }
    public Dictionary<string, object> Parameters { get; set; } = new();

    public DataCallSettings(string command)
    {
        SqlCommand = command;
    }

    public void AddParameter(string name, object value)
    {
        Parameters[name] = value;
    }

}

Take a look at the finished method with all of the changes that we made.

// In DatabaseConnectionProvider.cs

public List<T> GetRecords<T>(DataCallSettings dcs) where T : ISqlDataParser<T>, new()
{
    using (var connection = new SqliteConnection(_connectionString))
    {
        connection.Open();
        var command = connection.CreateCommand();
        command.CommandText = dcs.SqlCommand;

        foreach (var key in dcs.Parameters.Keys)
        {
            command.Parameters.AddWithValue(key, dcs.Parameters[key]);
        }

        var returnList = new List<T>();
        using (var reader = command.ExecuteReader())
        {
            while (reader.Read())
            {
                returnList.Add(new T().Parse(reader));
            }
        }
        connection.Close();

        return returnList;
    }
}

As a bonus, I'll also give you two lines of code that will let us get single records using all the hard work we did earlier.

public T GetRecord<T>(DataCallSettings dcs) where T : ISqlDataParser<T>, new()
=> GetRecords<T>(dcs).FirstOrDefault() ?? new();

The command

// In DatabaseConnectionProvider.cs
// After GetRecord<T>

public int Execute(DataCallSettings dcs)
{
    using (var connection = new SqliteConnection(_connectionString))
    {
        connection.Open();
        var command = connection.CreateCommand();
        command.CommandText = dcs.SqlCommand;

        foreach (var key in dcs.Parameters.Keys)
        {
            command.Parameters.AddWithValue(key, dcs.Parameters[key]);
        }

        var result = command.ExecuteNonQuery();
        connection.Close();
        return result;
    }
}

This is fine, but we're duplicating some logic between GetRecords and Execute. Let's lift it into a fancy new BuildCommand method.

// In DatabaseConnectionProvider.cs
// After Execute()

private SqliteCommand BuildCommand(DataCallSettings dcs, SqliteConnection connection)
{
    var command = connection.CreateCommand();
    command.CommandText = dcs.SqlCommand;

    foreach (var key in dcs.Parameters.Keys)
    {
        command.Parameters.AddWithValue(key, dcs.Parameters[key]);
    }

    return command;
}

And refactor both methods to use it.

// In DatabaseConnectionProvider.cs

// In GetRecords<T>
    connection.Open();
    var command = BuildCommand(dcs, connection);

    var returnList = new List<T>();

// In Execute()
    connection.Open();
    var command = BuildCommand(dcs, connection);

    var result = command.ExecuteNonQuery();

// In DatabaseConnectionProvider.cs
// Below Execute()

public int ExecuteWithIdentity(DataCallSettings dcs)
{
    if (!dcs.SqlCommand.StartsWith("INSERT"))
    {
        throw new InvalidOperationException();
    }

    using (var connection = new SqliteConnection(_connectionString))
    {
        connection.Open();
        dcs.SqlCommand = $"{dcs.SqlCommand} SELECT last_insert_rowid();";
        var command = BuildCommand(dcs, connection);

        var identity = Convert.ToInt32(command.ExecuteScalar());
        connection.Close();
        return identity;
    }
}

And with that... drumroll please.

We've done it! We've created, by hand, an way to interact with a database that is extensible and easy to use.

The repository

Adding a separate layer allows us to ignore the database's implementation details when we finally want to send this data to a front end somewhere. So, let's create a StudentsRepository.

// StudentsRepository.cs
using Students.Abstractions;
using Students.Models;

namespace Students.Repository.SQL;

public class StudentsRepository : IStudentsRepository
{

}

And here's the interface, complete with the methods that we're going to create.

using Students.Models;

namespace Students.Abstractions;

public interface IStudentsRepository
{
    Student GetStudent(int id);
    List<Student> GetStudents();
    int SaveStudent(Student student);
    bool DeleteStudent(int id);
}

// in StudentsRepository.cs

public class StudentsRepository : IStudentsRepository
{
    private readonly IDatabaseConnectionProvider _provider;

    StudentsRepository(IDatabaseConnectionProvider provider)
    {
        _provider = provider;
    }

    public Student GetStudent(int id)
    {
        var dcs = new DataCallSettings("SELECT * FROM students WHERE Id = @Id;");
        dcs.AddParameter("Id", id);
        return _provider.GetRecord<Student>(dcs);
    }

    public List<Student> GetStudents()
    {
        var dcs = new DataCallSettings("SELECT * FROM students;");
        return _provider.GetRecords<Student>(dcs);
    }

    public int SaveStudent(Student student)
        => student.Id == 0 // new student
            ? InsertStudent(student)
            : UpdateStudent(student);

    private int InsertStudent(Student student)
    {
        var dcs = new DataCallSettings("INSERT INTO students (name, school) VALUES (@Name, @School);");
        AddStudentParameters(dcs, student);
        return _provider.ExecuteWithIdentity(dcs);
    }

    private int UpdateStudent(Student student)
    {
        var dcs = new DataCallSettings("UPDATE students SET name = @Name, school = @School WHERE id = @Id;");
        dcs.AddParameter("Id", student.Id);
        AddStudentParameters(dcs, student);
        return _provider.Execute(dcs) > 0
            ? student.Id
            : 0;
    }

    public bool DeleteStudent(int id)
    {
        var dcs = new DataCallSettings("DELETE FROM students WHERE id = @Id");
        dcs.AddParameter("Id", id);
        return _provider.Execute(dcs) > 0;
    }

    private void AddStudentParameters(DataCallSettings dcs, Student student)
    {
        if (student.IsNew) { dcs.AddParameter("Id", student.Id); }
        dcs.AddParameter("Name", student.Name);
        dcs.AddParameter("School", student.School);
    }
}

The conclusion

The Perfect Programming Environment

Nolan Miller — Fri, 15 Aug 2025 13:43:24 +0000

I often encounter programming terms and lingo that goes way over my head when I'm browsing software engineering content on the internet. I wish that I could say that I drop everything and search these terms as soon as I see them, but this is rarely the case. But, this article is about a time that I took my medicine and not only looked up something I didn't understand, but implemented it into my daily workflow.

The term? —dotfiles

Centralized and Modular Configurations

What are dotfiles?

Maybe you're more hip than I was, but if you're not, let me fill you in. Dotfile is technical shorthand for a hidden file on your system that provides configuration settings to your operating system, shell, or applications. Most systems' preferred method of hiding files s to add a . at the beginning of the file—hence, dotfile.

Many developers choose to alter these files to exert a level of god-like control over their own computers (i.e. to change the color of their terminal prompt... ). Having these files spread across the computer can make them difficult to update and maintain, so it's convenient to package them together into a personal dotfiles git repository.

Alright, you're filled in, and I'll admit that on the face of it, dotfiles sound pretty boring. I expected this project to fulfill my neurotic need to organize, but in the end, I found that it presented interesting challenges to solve, and that this project represents the only project that I've built that I use daily.

Why I created my own dotfiles

I hesitate to write this, but Pewdiepie (yes, the Fortnite streamer) was actually the first inspiration for this project. After watching him install Arch, I went down a rabbit hole of customization possibilities for my own devices.

The discovery of this video coincided pretty closely with the beginning of my transition to Neovim (by the way). Neovim's configurations are all stored in text files, text files that are notoriously easy to break and hard to recover if you've made too many changes at once. It's a good idea to keep these tracked in a git repository, and to change them intentionally so that you can run git reset HEAD --hard when the worst happens.

I am not an Arch Linux user quite yet, but my current OS's were another motivation. I work on Windows and do personal development on Mac. If I want to make a change to my dev environment, I'm adjusting it in two places. Not all of the applications that I use are cross platform, but I still like to keep as much of the workflow the same as I can. This means that I wind up translating keyboard shortcuts and other configurations from one DSL to another. This is much easier, when everything is centralized.

Writing my own version-controlled and modular dotfiles repository solves all of these problems. But, I'd be lying if I said that the primary reason wasn't just that I like to tinker, and this may be one of the most fun ways to explore your operating system.

Making it your own

In 2010, developer and startup advisor, Zach Holman, wrote a piece called Dotfiles Are Meant To Be Forked, where he argues that some of the best developers have horribly disorganized configurations, and that a dotfiles repo should be well designed, personalized and extensible. He ends the article with an encouragement to get started:

So, fork it. Or, if not mine, then fork some of the awesome other projects I mentioned. Or come up with your own way of organizing your stuff and share it. Everyone’s got their own way of streamlining their system, and sharing dotfiles helps everyone.

I would only alter this advice slightly. If you haven't created your own dotfiles repository before, start from scratch. Before going to see what other people have done, find out what problems you are trying to solve for your workflow. Once you've done this, digging into someone else's configurations can give you inspiration for things to change. But, I've found that adding configurations from others has led to creating features that I never use, and a more difficult to maintain repository that is cluttered with unnecessary configurations.

This might sound strange coming from a blogger who is about to tell you about his own dotfiles. My goal with this article is not to show you every inch of my configuration. In fact, I won't discuss most of the configurations at all. Rather, I want to give you a skeleton that will get your own repository working. The questions that I will answer today are: "How do I centralize my config files?" and "How can I make them modular?"

I'm hoping that removing this barrier makes it easier for you to joyfully discover your preferences, your operating system, and new tools and applications shared by the community.

Building Dotfiles

Centralizing configurations

The first problem to solve when creating a dotfiles repo is getting all of your configurations into one directory without breaking all of the software and firmware that read from them. These files are typically located in a few different locations on your computer. That means the configurations aren't portable or easily maintainable. To solve this we need a way to tell our computer where to look for our configuration files.

Luckily, the solution for this is built into your operating system. It's called symbolic linking or symlinking.

When we boot up, say, Neovim (by the way), the application tries to set its configuration by looking for files. By default, it goes to my user directory for this path ~/.config/nvim. We could just put the configuration files there, or we could put a symlink there that basically says, "This file that you're looking for is over there." The computer will redirect to the linked file or files and read them as if they are in the location of the symlink.

Let's take another example, a .zshrc file that contains some customizations on my terminal prompt. For my terminal to read this file, it has to be in my user directory. If I want to keep this file in my dotfiles repo I'll create a symlink at ~/.zshrc that points to /Projects/dotfiles/.zshrc. Now when the computer goes to ~/.zshrc it's invisibly redirected to the file at /Projects/dotfiles/.zshrc. My terminal can read its configurations and I get to keep them in a tidy folder with all my other configurations.

Implementing a link in a unix-based environment is as simple as running the command:

ln -sf [source] [link]

... where source is the file in your dotfiles and link is the location that you want to put the link.

The following script will allow you to quickly add source/link pairs.

# Create an associative array for source/target pairs
typeset -A links
links=(
  "$DOTFILES/mac/.zshrc" "$HOME/.zshrc"
  "$DOTFILES/mac/.zprofile" "$HOME/.zprofile"
  "$DOTFILES/mac/.zshenv" "$HOME/.zshenv"
  "$DOTFILES/shared/nvim" "$HOME/.config"
)

# Loop through each key in the associative array
for source in "${(@k)links}"; do
  link="${links[$source]}"
  backup="$link.backup"

  # Check if the link target or [target].backup exists
  if [[ -e "$link" && ! -e "$backup" ]]; then
      if [[ ! -d "$link" ]]; then
        # Backup any existing configuration files (just in case)
        mv -f "$link" "$backup"
        echo "Backed up: $backup"
      fi
  fi

  # This section handles making sure that parent directories exist
  #
  # Checking if the source is a directory and the
  # target doesn't exist
  if [[ -d "$source" && ! -e "$link" ]]; then
      mkdir -p "$link"
  else
      # We need to split the file name off of the path to 
      # create all the parent directories.
      parent_dir="${link:h}"
      mkdir -p "$parent_dir"
  fi 

  # Create the link
  ln -sf "$source" "$link"

  if [[ -d "$source" ]]; then
      echo "Linked ${source:t} directory to $link"
  else
      echo "Linked ${source:t} to $link"
  fi
done

As you need to centralize more files, and create more links, they can quickly be added to the links array at the top, and the links will automatically be created. As I encounter more configurations across my system that I'd like to change, it's very simple to add them here, link them, and run the script. The friction to making changes now is pretty much gone.

Making them modular

While having everything in one place makes things easier to maintain, if the files get unmanageably long, then that friction comes back. So, combining related configurations into well-named files is a must. I'll focus here on two methods to modularize your configuration files, one for language-based configurations and one for plaintext configurations.

If you're interested in the structure that I use to modularize the configurations of my different operating systems, check out the repository.

Scripting-Language Configurations

When splitting up configurations into multiple files, it's important to know the configuration language of the application. Sometimes, this is a Turing-complete language like Bash or Lua, but other times its a domain specific language (DSL) that can only be used with that piece of software.

When we scripting languages, the way that we make things modular is a bit more straightforward. Let's look at my .zshrc for example. I want to customize my prompt, add some functions and keep aliases as shortcuts to different locations on my drive. Since, the .zshrc is written in Zsh (very similar to Bash), I can organize my configurations into separate files like this:

dotfiles/
├── shell/
|   ├── aliases.sh
|   ├── functions.sh
|   └── prompt.sh
├── .zshrc
└── bootstrap.zsh

My shell is still going to look for a .zshrc file, not our modules. Instead of jamming all of our configurations in the file, we will tell it to look for our dotfiles repository and loop through the shell subdirector and source every readable file that ends in .sh.

DOTFILES="$HOME/Path/To/dotfiles"

for FILE in $DOTFILES/shell/*.sh; do
    [ -r $FILE ] && source "$FILE"
done

DSL / Plaintext Configuration

While DSLs can still be Turing-complete, many configuration languages aren't, which means that we don't have access to helpful things like conditionals or loops. To make modular configurations, we are going to have to construct the source files from our modules using a scripting language.

For my tmux configuration I have a similar directory structure to my shell configurations.

dotfiles/
├── tmux/
|   ├── theme.conf
|   ├── bindings.conf
|   └── general.conf
├── .tmux.conf
└── bootstrap.zsh

Notice that we still have a modular structure. But, our .tmux.conf file is written in plaintext, it's not executable, so we can't loop through the tmux/ directory there. Instead, we have to write a function that can write our .tmux.conf to use in bootstrap.zsh:

write_conf () {
    local dir=$1
    local out=$2

    cat $dir/* > "$out"
    echo "# Conf written on $(gdate)" >> "$out"
}

write_conf "$DOTFILES/tmux" "$DOTFILES/.tmux.conf"

Now for every plaintext configuration, we can write every file in a given directory to a single file. I also added a timestamp to the end of the file to make sure the bootstrap script ran properly.

Why I don't like forking

You can get a lot of ideas for your own configurations by perusing my dotfiles, or any of the dotfiles that many people share on reddit, or GitHub or other sites. However, I think that if you're just starting, forking someone else's configurations can side-step the the self-discovery and growth than comes from starting from scratch.

By all means, take inspiration from others, but the goal is to solve the problems that you have on your system. If you start with a fork dotfiles, you're getting someone else's solutions to someone else's problems. Often, these solutions have way more configurations that you want or need, because you're jumping into a repository that may have been built on for years. For me, that kind of starting point is overwhelming and adds friction when there are changes that I want to make.

But, they're your dotfiles.

So, do what you want. If you want to fork, fork. If you want to start from scratch, start from scratch. Nobody's opinion on your dotfiles matters because they are uniquely yours, for your computer, your workflow, and your enjoyment.

Happy scripting!

Quidditch - Powered By PostgreSQL and ASP.NET

Nolan Miller — Thu, 24 Jul 2025 19:24:06 +0000

As a software developer, it's important to work on your craft. That's why I've been studying ASP.NET for the past few months. In my last article I walk through how to set up an ASP.NET Minimal Web API. Today, I'll be building on that foundation, by adding a persistent data store, a la PostgreSQL. In order to configure a .NET API to communicate with a PostgreSQL database, I'm going to use Entity Framework.

Though I could have worked with my animal sounds API, I decided to implement the database for an app that scores a road trip game that my wife and I took this summer.
I recently saw a video about a new road trip game that's inspired by Harry Potter (my favorite book series). I knew that my wife and I had to try it. If you're interested, the rules of the game are described in this video, and you can play using my score tracker at https://quidditchtrip.nolanmiller.me.

In this article, I'll go over making sure that you have PostgreSQL installed and running, and then how to install and configure Entity Framework to read to and write from the database.

What you'll need to start:

A .NET Web API (that you've created using the dotnet CLI)
Access to an internet connection
A little bit of patience

Install Postgres

There are a few different methods to installing and starting a Postgres server on your machine, but the easiest route is downloading Postgres.app, a MacOS postgres server interface that comes bundled with the psql CLI. If you're not on Mac, or if you're interested in other installation methods the official Postgres website has installation instructions for every operating system and includes instructions for other installation methods.

Once you're done you should be able to start your Postgres server and also connect to it using the psql command line interface.

Create a database

Before we can start creating our models and writing data, we need to make sure that we have a database for our application. To do this, connect to psql using the following command:

psql -U postgres

This will connect us to the Postgres server with the default user postgres. If it prompts you for a password, it should be the default password, postgres.

Once you're connected you should see a prompt that ends with # and we can issue the following SQL command:

postgres=# CREATE DATABASE Quidditch;

Since this database is for my Quidditch app, I'll name it Quidditch, just replace this with whatever name makes sense for your application.

Connect to your database

With a database set up, it can be connected to our .NET application using Entity Framework, an object-relational mapper for the .NET ecosystem. EF will automate reading and writing data on our database, and handle table creation and modifications through the development process.

To get started with EF for Postgres, install two NuGet packages by running the following commands from a terminal in your .NET project:

dotnet add package Microsoft.EntityFrameworkCore.PostgreSQL
dotnet add package Microsoft.EntityFrameworkCore.Design

To interact with a database we have to create a database context to allow us to interface with the database, configure the context object to use the proper connection string, set up models and create a migration using EF that will scaffold our database.

1. Database Context

To create a database context, create a class that inherits from EF's DbContext class, like so:

using Microsoft.EntityFrameworkCore;

public class QuidditchContext : DbContext
{
    public QuidditchContext(DbConextOptions<QuidditchContext> options) : base(options) { }
}

Then wire it into your Program.cs file.

// in Program.cs
var connectionString = "[Your connection string]";
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddDbContext<QuidditchContext>(options => options.UseNpgsql(connectionString));

This way of setting a connection string isn't secure, and should only be used for testing. Make sure that you load these in via a config file!

And with these two small additions, Entity Framework can access your database server.

2. Set up models

The next step in configuration is defining the models that we want to persist. For my Quidditch game, since it's a simple score tracker, I really only need to capture two data models: games and teams. Instead of creating two database tables for these and setting up their columns, I can just create the model in my C# code and EF will reason out the structure of the database!

public class Team
{
    public int TeamKey { get; set; }
    public string Name { get; set; }
    public int Score { get; set; }
    public bool IsActive { get; set; }
    public DateTime CreatedDateTime { get; set; }
    public int? GameKey { get; set; }

    [JsonIgnore]
    public Game Game { get; set; }
}

public class Game
{
    public int GameKey { get; set; }
    public DateTime GameStartDateTime { get; set; }
    public DateTime? GameEndDateTime { get; set; }
    public bool IsActive { get; set; } = true;
    public bool IsFinished => GameEndDateTime != null;

    public List<Team> Teams { get; set; } = new List<Team>();
}

A couple of things to point out here. First, I'm using the terminology [Entity]Key to define my primary keys. This is not automatically picked up by EF. They would prefer that you use [Entity]Id instead. Unfortunately, I am stubborn and would have been mistyping "Key" instead of "Id" of for the whole project, so I took the extra couple of steps to define my keys and relationships.

When I add these models to my database context in the next step, EF will use these models to set up tables and columns based on them. Not everything will be one for one though. There are two special properties here. The Team.Game property and the Game.Teams properties are called Navigations.

A Navigation property models a relationship between two tables. They work by associating related models using primary and foreign keys on the models and are kept in sync by EF.

Before these will behave as expected, we need to register these models in our DbContext with DbSet properties. This can be done as easily as adding properties to any other class, but set the type to DbSet<[Entity]> where [Entity] is the model that you want to register.

// QuidditchContext
public class QuidditchContext : DbContext
{
    public QuidditchContext(DbConextOptions<QuidditchContext> options) : base(options) { }

    public DbSet<Team> Teams { get; set; }
    public DbSet<Game> Games { get; set; }
}

The DbSet<> class comes from Entity Framework and inherits from IEnumerable<T>, which allows us to use LINQ (and some Entity Framework specific versions of LINQ) to access our models.

Since I decided to use a different convention for my primary and foreign keys, I have another configuring step to define the relationships between my tables. To manually define table and column relationships, override the OnModelCreating method in DbContext. The relationships that I used are below.

public class QuidditchContext : DbContext
{
    // ...
    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        // .HasKey tell EF what the name of the primary key should be
        modelBuilder.Entity<Team>()
            .HasKey(t => t.TeamKey);

        modelBuilder.Entity<Game>()
            .HasKey(g => g.GameKey);

        // These methods define the one-to-many relationship in
        // what looks like plain language. 
        modelBuilder.Entity<Team>()
            .HasOne(e => e.Game)
            .WithMany(e => e.Teams)
            .HasForeignKey(t => t.GameKey)
            .OnDelete(DeleteBehavior.SetNull);
        // .OnDelete can set what happens to related tables
        // when the record they reference is deleted.

        // I don't want a table to be created for this model.
        modelBuilder.Ignore<LeaderboardEntry>();
    }

Even if you're not using custom naming for your properties, it is probably a good idea to override this method so that your complex relationships are explicitly set by you. This will help mitigate unexpected behavior and has the added benefit of providing some in-code documentation.

Now that configuration is done, it's time to create a database through a process called migration.

3. Create a migration

As you work on a project, inevitably the shape of your data will change here and there. Instead of manually updating your database tables, Entity Framework handles this through migrations.

Since the models are already defined in the code, Entity Framework can scaffold and re-scaffold database, throughout the lifecycle of the application. A migration can be created using the dotnet CLI with the following command.

dotnet ef migrations add InitialCreate

With dotnet ef the Entity Framework-specific tools are specified, and then using the migrations add command a migration is created called InitialCreate. A migration can have any name, but it's a good idea to give it a descriptive title for when you need to roll your changes back.

To finalize the changes on our database (or "creation of" in this instance) we still have to run one more command. EF separates this process of updating the database into two steps. In the first step, a few things happen:

a Migrations directory is created in the root of your project if not already there
a [TIMESTAMP]_InitialCreate.cs file is generated, containing the steps to implement the changes to your context, and steps to walk it back if needed.
a [TIMESTAMP]_InitialCreate.Designer.cs file is generated with metadata for EF to use.
a MyContextModelSnapshot.cs file containing a current snapshot of your context model is created.

The syntax in these files is fairly easy to interpret, so it's a good idea to do a once-over of the Up method in the [TIMESTAMP]_InitialCreate.cs method so that you aren't surprised by any changes!

Now to finalize those changes and apply them to the database run the following command.

dotnet ef database update

This will updates the database to the most recent migration. Be careful as you do this, there is potential for data loss when running this command! Now, the database and it's tables are set up and ready for you to start querying!

Using LINQ to access your data

To illustrate how to query a database using Entity Framework, take a look at one of the service methods that I created for my application:

public async Task<ServiceResponse<Game>> GetGameByKey(int gameKey)
{
    var game = await _context.Games
        .Include(g => g.Teams)
        .SingleAsync(g => g.GameKey == gameKey);
    if (game == null) { return ServiceResponse<Game>.Failure("..."); }
    return ServiceResponse<Game>.Success(game);
}

If you're familiar with LINQ syntax, then this should be familiar.

public async Task<ServiceResponse<Game>> GetGameByKey(int gameKey)

First, I'm declaring a method called GetGameByKey, that returns a custom response object with the generic type Game. I just created a response class with a generic Payload property so that I can send back metadata along with the requested models if needed.

var game = await _context.Games
        .Include(g => g.Teams)
        .SingleAsync(g => g.GameKey == gameKey);

This line queries the database, translating the database record into a usable model and assigning it to a variable that we can return from the method! By default, navigation properties are not included, but using .Include() and specifying the navigation property includes the related navigation in the query.

Query execution is signaled by the .SingleAsync() method, which works the same way as .Single() in LINQ. So this query, will return a only a single record where the GameKey column's value is equal to the gameKey argument passed in when this method is called.

Here's another method example:

public async Task<ServiceResponse<Game>> SetGameInactive(int gameKey)
{
    var gameResponse = await GetGameByKey(gameKey);
    if (!gameResponse.WasSuccessful) { return gameResponse; }
    var game = gameResponse.Payload;

    game.IsActive = false;
    _context.Games.Update(game);
    var changedRows = await _context.SaveChangesAsync();
    if (changedRows < 1) { return ServiceResponse<Game>.Failure("Failed."); }

    return ServiceResponse<Game>.Success(game);
}

There's a little more logic going on in this method. The goal is to find the Game with the matching GameKey and then set its IsActive property to false. The Game is retrieved in the same way as the first method we looked at. Once it's been accessed, then it's properties can be updated like any other class instance in C#.

The _context.Games.Update() method prepares EF to send the command to the database. Unlike the first query, the execution is started by SaveChangesAsync(), which returns the number of affected rows. This is the EF pattern for modifying existing data. The changes are made in the code, and SaveChanges() or SaveChangesAsync() must be called.

I hope that this shows just how simple it can be to access the data from a database using familiar C# list patterns. For a full list of methods available to Entity Framework, check out their documentation.

Summary

If you made it this far, thank you for reading! I hope that you found it helpful and I wish you the best of luck in implementing EF Core into your own C# applications.

This was a unique challenge for me. I primarily write in C# for my job, but we use a custom data access library that requires mapping our models manually. While Entity Framework has some nice quality-of-life features, I found that lose some of the flexibility gained by writing your own SQL.

This was a very simple project, but even still, it felt like I didn't save much time by using an ORM. Rather than save time on having to write SQL, I traded that time for configuring my database and tables in C#.

In my day job, I rely on libraries that have been provided for me, so I'm looking forward to learning how to implement database connections on my own. I don't know that I would choose to use Entity Framework again. I liked how easy it was to set up my models and navigations made implementing business logic very nice, but the configuration of relationships just wasn't as straightforward as it is in SQL.

Regardless, it is always good to take some time to learn new technologies.

Thanks again for reading!

Intro to .NET APIs for a JavaScript Developer

Nolan Miller — Tue, 27 May 2025 12:34:27 +0000

When I was applying like crazy to developer jobs, I'd scroll past so many .NET focused ones, thinking, "I'm only a JavaScript developer."

I felt lied to.

The internet told me "JavaScript can do it all," but, I felt like the skills that I'd learned would never land me a job. When I did find a primarily JavaScript job, it always had so many applicants that I felt like I didn't have a chance.

As of October 2024, JavaScript was still the second most used language on GitHub (though it was just over taken by Python). Check out this blog post from GitHub. But even though there's so much JavaScript code, that doesn't mean that the job market for it is thriving.

In my experience, the jobs with a .NET focus on job boards were:

... looking for more experience, but appeared to be more flexible.
... were paying higher starting salaries, and
... not attracting very many applicants AT ALL.

JavaScript's reputation for being easy to learn, means that WAY MORE people know it, paradoxically requiring you to be even more experienced to compete in the job market.

I just started programming, I can't code in C#!

The first time I looked at C#, it was intimidating. Sure, it uses curly braces, but the boilerplate code is deeply nested, I don't know any of the libraries available, and EVERYTHING IS IN PASCAL CASE.

The .NET ecosystem is a mature, reliable framework used to develop stable applications in many environments, but it can feel pretty unapproachable to newbies.

But, C# has a template that will feel very familiar to an intermediate JavaScript developer. A starting place, where you can begin to create useful apps and also begin to wrap your mind around the syntax and features of C# in ASP.NET.

An unconventional starting point

Start with a simple API. To be more specific, use the Minimal API template. The MVC model, especially when you're starting out, can be overwhelming. So, why start with an API? Because it's a simple way to integrate .NET into something that you're already working on. Have a React application? Well then let it consume your ASP.NET Minimal API as the backend.

You'll probably be surprised that the things you learned as a JavaScript developer (especially if you're using Express.js to build your APIs), will have strong carry over into the .NET ecosystem.

So, let's get up to speed on what a Minimal API even is, and then I'll walk you through how to get your own Minimal API up and running by the end of this post!

What Are Minimal APIs?

With .NET 6, Microsoft released Minimal APIs. This is opposed to the Controller-based API pattern that is common in .NET. Minimal APIs is that remove a lot of unnecessary boilerplate code that you need to create endpoint routes in a controller-based APIs.

Here's why this is good news for Javascript developers looking to get into .NET. The removal of this boilerplate code makes the syntax look very similar to the syntax used to build an API on Node with Express.js.

Side-by-Side Comparison: Express.js vs. Minimal APIs

To show you how approachable this can be, I'm going to create a GET and POST route and point out the similarities between the C# Minimal API version and the Express.js version

So let's set up the .NET Minimal API first.

// set up api
using Microsoft.AspNetCore.Mvc;

namespace MinimalAPI
{
    public class Program
    {
        public static void Main(string[] args)
        {
            var builder = WebApplication.CreateBuilder(args);
            var app = builder.Build();

            // ... add endpoints and middleware here

            Console.WriteLine("Server is running on port 3000.");
            app.Run("http://localhost:3000");
        }
    }
}

If this syntax is new to you, let me walk you through it. We're first referencing the Microsoft.AspNetCore.Mvc which contains the Builder class that we will use to construct our application. We call the build() method on the builder and then run our application while specifying the port.

Now, to set up the same application on Node in Express.js we would write the following.

// set up express app
const express = require('express');

const app = express();

// ... add endpoints and middleware here

app.listen(3000, () => {
    console.log("Server is running on port 3000");
})

Notice how similar. We require Express, which abstracts our builder logic. Then we run the application, specifying the port!

Creating Endpoints

The syntax is even more similar between these two frameworks for endpoint creation. Using the app that our builder created we the correct endpoint verb creation method to create the endpoint listener. In ASP.NET, this will look like this.

app.MapGet("/", (HttpRequest request, HttpResponse response) =>
{
    return "Hello World";
});

This pattern is nearly identical to what we would write in Express.js.

app.get("/", (req, res) => {
    res.send("Hello World");
})

In both the Minimal API and the Express API, we pass the endpoint route as the first parameters, and the callback function as the second.

Get started with ASP.NET

If you're tired of seeing job postings you feel that you can't apply for, then start learning C#! It doesn't have to be scary, or overly complex. And, I hope that I've shown that with the knowledge that you have already, you can get started in creating a useful application that has the potential to solve real world problems.

There are numerous free resources to get started with the basics of C#, and if it's your first strongly typed language, there will probably be some hurdles. But, once you get through the initial learning phase, so many of the skills you've already developed will transfer over.

Over the past several months, I've been diving deeper into ASP.NET. Check out some of my posts that detail my journey!