{"slug": "build-a-database-connection-framework-in-133-lines-of-code", "title": "Build a Database Connection Framework In 133 Lines Of Code", "summary": "This article explains how to build a custom database connection framework for ASP.NET minimal APIs using ADO.NET and SQLite, replacing Entity Framework to gain full control over SQL queries. The author demonstrates creating a `DatabaseConnectionProvider` class that uses `Microsoft.Data.Sqlite` to connect to a local SQLite database, with instructions for setting up student and grades tables. The framework is designed to be implemented in approximately 133 lines of code, offering a lightweight alternative to Entity Framework while maintaining C# object mapping capabilities.", "body_md": "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.\n\nIn 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.\n\n## The data\n\nFirst, 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.)\n\nWith our database, we'll track student information and grades. First, connect to SQLite and create a database, we'll call it `Students.db`\n\n, then create a `students`\n\ntable and a `grades`\n\ntable.\n\n```\nsqlite3 Students.db\nsqlite> CREATE TABLE students (\n...>        id INTEGER PRIMARY KEY,\n...>        name TEXT,\n...>        school TEXT\n...> );\nsqlite> CREATE TABLE grades (\n...>        id INTEGER PRIMARY KEY,\n...>        scored INTEGER,\n...>        out_of INTEGER,\n...>        student_id INTEGER,\n...>        FOREIGN KEY (student_id) REFERENCES students(id)\n...> );\n```\n\nDrop 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.\n\n## The connection\n\nInstead 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:\n\n```\ndotnet add package Microsoft.Data.Sqlite\n```\n\nWith 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:\n\n`\"Data Source=path/to/database_file.db\"`\n\nThe best way to give your application access to this is through a configuration object that you supply through dependency injection. I wrote [an article](https://nolanmiller.me/posts/learn-application-configuration-in-asp.net/) 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.\n\nIt'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`\n\n.\n\n```\n// DatabaseConnectionProvider.cs\nusing Microsoft.Data.Sqlite;\n\nnamespace Students.Repository.SQL;\n\npublic class DatabaseConnectionProvider : IDatabaseConnectionProvider\n{\n    private readonly string _connectionString;\n\n    public DatabaseConnectionProvider(IConfiguration config)\n    {\n        // Don't you hard code it, cowboy...\n        _connectionString = config[\"ConnectionString\"]!;\n        if (string.IsNullOrEmpty(_connectionString))\n        {\n            throw new InvalidOperationException(\"Connection string not found.\");\n        }\n    }\n}\n```\n\nSince 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!\n\n```\n// IDatabaseConnectionProvider.cs\nnamespace Students.Abstractions;\n\npublic interface IDatabaseConnectionProvider\n{\n    List<T> GetRecords<T>();\n}\n```\n\nNow back in our provider class, create the database connection inside this `GetRecords`\n\nmethod.\n\n```\n// DatabaseConnectionProvider.cs \n// after DatabaseConnectionProvider(IConfigration)\n\n    public List<T> GetRecords()\n    {\n        using (var connection = new SqliteConnection(_connectionString))\n        {\n            connection.Open();\n            var command = connection.CreateCommand();\n            command.CommandText = \"SELECT * FROM students;\";\n\n            var reader = command.ExecuteReader();\n            while (reader.Read())\n            {\n                Console.WriteLine(reader[\"name\"].ToString())\n            }\n            connection.Close();\n            return new List<T>();\n        }\n    }\n```\n\nThe `SqliteConnection`\n\nclass 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.\n\nThis isn't our final `GetRecords`\n\nimplementation, 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 *`\n\ncommand to return all the students. We get back a `DataReader`\n\n, also provided by the NuGet package from earlier, that we can use to read the `\"name\"`\n\ncolumn of each row before disposing the connection.\n\nWe're connected! Take a moment to [celebrate](https://giphy.com/gifs/animation-portal-the-cake-is-a-lie-3oEduOEWGS68758rXq).\n\n## The models\n\nNow 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.\n\nIn this small sample project, we just need two.\n\n```\n// Student.cs\npublic class Student\n{\n    public int Id { get; set; }\n    public string Name { get; set; } = string.Empty;\n    public string School { get; set; } = string.Empty;\n}\n\n// Grade.cs\npublic class Grade\n{\n    public int Id { get; set; }\n    public int Scored { get; set; }\n    public int OutOf { get; set; }\n    public int StudentId { get; set; }\n}\n```\n\nOne 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`\n\nto spit out these models that we just created?\n\nOnce 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`\n\n, since attempting to query for grades would throw an exception when looking for the `\"name\"`\n\nor the `\"school\"`\n\ncolumns.\n\nWell, then we could create a new `GetGradeRecords`\n\n, 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.\n\nInstead, we need to offload the parsing responsibility from our `DatabaseConnectionProvider`\n\n. 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`\n\nmethod.\n\n```\n// In Student.cs \n    public string School { get; set; } = string.Empty;\n\n    public Student Parse(IDataReader reader)\n    {\n        Id = reader.ParseInt(\"id\");\n        Name = reader.ParseString(\"name\");\n        School = reader.ParseString(\"school\");\n\n        return this;\n    }\n}\n\n// In Grade.cs\n    public int StudentId { get; set; }\n\n    public Grade Parse(IDataReader reader)\n    {\n        Id = reader.ParseInt(\"id\");\n        Scored = reader.ParseInt(\"scored\");\n        OutOf = reader.ParseInt(\"out_of\");\n        StudentId = reader.ParseInt(\"student_id\");\n\n        return this;\n    }\n}\n```\n\nIf you're typing along, you probably noticed that `ParseInt`\n\nand `ParseString`\n\nare red. In order to clean up the syntax a bit, I added a couple static extensions methods on the `DataReader`\n\nclass. You can add those in a new file.\n\n```\nusing System.Data;\n\nnamespace Students.Repository.SQL;\n\npublic static class ReaderExtensions()\n{\n    public static int ParseInt(this IDataReader reader, string columnName)\n    {\n        return reader.GetInt32(reader.GetOrdinal(columnName));\n    }\n\n    public static string ParseString(this IDataReader reader, string columnName)\n    {\n        return reader.GetString(reader.GetOrdinal(columnName));\n    }\n}\n```\n\nNow all we have to do is let the `DatabaseConnectionProvider`\n\nknow 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...\n\n```\n// ISqlDataParser.cs\nusing System.Data;\n\nnamespace Students.Abstractions;\n\npublic interface ISqlDataParser<T>\n{\n    T Parse(IDataReader reader);\n}\n```\n\n... and make sure that our models are inheriting it.\n\n```\n// Student.cs\npublic class Student : ISqlDataParser<Student>\n\n// Grade.cs\npublic class Grade : ISqlDataParser<Grade>\n```\n\nNow, let's update our `GetRecords`\n\ndeclaration to finish making our `Parse`\n\nmethods available.\n\n```\n// In DatabaseConnectionProvider\n// Replace public List<T> GetRecords()\npublic List<T> GetRecords() where T : ISqlDataParser<T>, new()\n```\n\nWhat this says, is that we can only call `GetRecords<T>`\n\nif the type that we insert for `T`\n\nimplements the `ISqlDataParser`\n\ninterface and has a parameter-less constructor.\n\nNow that we can safely access `Parse`\n\nwe can use it in `GetRecords<T>`\n\n.\n\n```\n// In DatabaseConnectionProvider.cs\n// In GetRecords<T>\n// Replace everything after:  var reader = command.ExecuteReader();\n\n        var returnList = new List<T>();\n        using (var reader = command.ExecuteReader())\n        {\n            while (reader.Read())\n            {\n                returnList.Add(new T().Parse(reader));\n            }\n        }\n        connection.Close();\n        return returnList;\n    }\n}\n```\n\n## The query\n\nRight now, we're in an interesting state. The `GetRecords`\n\nmethod 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.\n\nSimilar to what we did with the `Parse`\n\nmethod, we need to take away the `DatabaseConnectionProvider`\n\n'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.\n\nIf only add a `string`\n\nparameter to the method, but then we don't have access to the `Command`\n\nobject.\n\nSo what?\n\nThe `Command`\n\nobject is where we add `SqlParameters`\n\n. 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`\n\nobject against SQL injection attacks. No matter the sanitation that we do, adding the parameters to the correct property on the `Command`\n\nobject is the smartest way forward.\n\nIn 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`\n\n(naming is hard).\n\n```\n// DataCallSettings.cs\nnamespace Students.Models;\n\npublic class DataCallSettings\n{\n    public string SqlCommand { get; set; }\n    public Dictionary<string, object> Parameters { get; set; } = new();\n\n    public DataCallSettings(string command)\n    {\n        SqlCommand = command;\n    }\n\n    public void AddParameter(string name, object value)\n    {\n        Parameters[name] = value;\n    }\n\n}\n```\n\nThis class is now the only parameter to `GetRecords<T>`\n\n. 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.\n\nTake a look at the finished method with all of the changes that we made.\n\n```\n// In DatabaseConnectionProvider.cs\n\npublic List<T> GetRecords<T>(DataCallSettings dcs) where T : ISqlDataParser<T>, new()\n{\n    using (var connection = new SqliteConnection(_connectionString))\n    {\n        connection.Open();\n        var command = connection.CreateCommand();\n        command.CommandText = dcs.SqlCommand;\n\n        foreach (var key in dcs.Parameters.Keys)\n        {\n            command.Parameters.AddWithValue(key, dcs.Parameters[key]);\n        }\n\n        var returnList = new List<T>();\n        using (var reader = command.ExecuteReader())\n        {\n            while (reader.Read())\n            {\n                returnList.Add(new T().Parse(reader));\n            }\n        }\n        connection.Close();\n\n        return returnList;\n    }\n}\n```\n\nAs 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.\n\n```\npublic T GetRecord<T>(DataCallSettings dcs) where T : ISqlDataParser<T>, new()\n=> GetRecords<T>(dcs).FirstOrDefault() ?? new();\n```\n\n## The command\n\nSometimes 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`\n\nmethod, but we will use the `.ExecuteNonQuery()`\n\nmethod instead, and we'll call it `Execute`\n\n. *Creative... I know.*\n\n```\n// In DatabaseConnectionProvider.cs\n// After GetRecord<T>\n\npublic int Execute(DataCallSettings dcs)\n{\n    using (var connection = new SqliteConnection(_connectionString))\n    {\n        connection.Open();\n        var command = connection.CreateCommand();\n        command.CommandText = dcs.SqlCommand;\n\n        foreach (var key in dcs.Parameters.Keys)\n        {\n            command.Parameters.AddWithValue(key, dcs.Parameters[key]);\n        }\n\n        var result = command.ExecuteNonQuery();\n        connection.Close();\n        return result;\n    }\n}\n```\n\nThis is fine, but we're duplicating some logic between `GetRecords`\n\nand `Execute`\n\n. Let's lift it into a fancy new `BuildCommand`\n\nmethod.\n\n```\n// In DatabaseConnectionProvider.cs\n// After Execute()\n\nprivate SqliteCommand BuildCommand(DataCallSettings dcs, SqliteConnection connection)\n{\n    var command = connection.CreateCommand();\n    command.CommandText = dcs.SqlCommand;\n\n    foreach (var key in dcs.Parameters.Keys)\n    {\n        command.Parameters.AddWithValue(key, dcs.Parameters[key]);\n    }\n\n    return command;\n}\n```\n\nAnd refactor both methods to use it.\n\n```\n// In DatabaseConnectionProvider.cs\n\n// In GetRecords<T>\n    connection.Open();\n    var command = BuildCommand(dcs, connection);\n\n    var returnList = new List<T>();\n\n// In Execute()\n    connection.Open();\n    var command = BuildCommand(dcs, connection);\n\n    var result = command.ExecuteNonQuery();\n```\n\nAh, 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.\n\n```\n// In DatabaseConnectionProvider.cs\n// Below Execute()\n\npublic int ExecuteWithIdentity(DataCallSettings dcs)\n{\n    if (!dcs.SqlCommand.StartsWith(\"INSERT\"))\n    {\n        throw new InvalidOperationException();\n    }\n\n    using (var connection = new SqliteConnection(_connectionString))\n    {\n        connection.Open();\n        dcs.SqlCommand = $\"{dcs.SqlCommand} SELECT last_insert_rowid();\";\n        var command = BuildCommand(dcs, connection);\n\n        var identity = Convert.ToInt32(command.ExecuteScalar());\n        connection.Close();\n        return identity;\n    }\n}\n```\n\nAnd with that... drumroll please.\n\nWe've done it! We've created, by hand, an way to interact with a database that is extensible and easy to use.\n\n## The repository\n\nNow 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.\n\nAdding 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`\n\n.\n\n```\n// StudentsRepository.cs\nusing Students.Abstractions;\nusing Students.Models;\n\nnamespace Students.Repository.SQL;\n\npublic class StudentsRepository : IStudentsRepository\n{\n\n}\n```\n\nAnd here's the interface, complete with the methods that we're going to create.\n\n```\nusing Students.Models;\n\nnamespace Students.Abstractions;\n\npublic interface IStudentsRepository\n{\n    Student GetStudent(int id);\n    List<Student> GetStudents();\n    int SaveStudent(Student student);\n    bool DeleteStudent(int id);\n}\n```\n\nThen, back in our repository, we will inject our `DatabaseConnectionProvider`\n\n. Make sure that it's registered in your `Program.cs`\n\nfile first though. Here's [an article](https://nolanmiller.me/posts/what-is-dependency-injection/) that walks through DI in ASP.NET if you need some help with that.\n\nFinishing the implementation now is as simple as calling the appropriate provider method with a `DataCallSettings`\n\ninstance 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.\n\n```\n// in StudentsRepository.cs\n\npublic class StudentsRepository : IStudentsRepository\n{\n    private readonly IDatabaseConnectionProvider _provider;\n\n    StudentsRepository(IDatabaseConnectionProvider provider)\n    {\n        _provider = provider;\n    }\n\n    public Student GetStudent(int id)\n    {\n        var dcs = new DataCallSettings(\"SELECT * FROM students WHERE Id = @Id;\");\n        dcs.AddParameter(\"Id\", id);\n        return _provider.GetRecord<Student>(dcs);\n    }\n\n    public List<Student> GetStudents()\n    {\n        var dcs = new DataCallSettings(\"SELECT * FROM students;\");\n        return _provider.GetRecords<Student>(dcs);\n    }\n\n    public int SaveStudent(Student student)\n        => student.Id == 0 // new student\n            ? InsertStudent(student)\n            : UpdateStudent(student);\n\n    private int InsertStudent(Student student)\n    {\n        var dcs = new DataCallSettings(\"INSERT INTO students (name, school) VALUES (@Name, @School);\");\n        AddStudentParameters(dcs, student);\n        return _provider.ExecuteWithIdentity(dcs);\n    }\n\n    private int UpdateStudent(Student student)\n    {\n        var dcs = new DataCallSettings(\"UPDATE students SET name = @Name, school = @School WHERE id = @Id;\");\n        dcs.AddParameter(\"Id\", student.Id);\n        AddStudentParameters(dcs, student);\n        return _provider.Execute(dcs) > 0\n            ? student.Id\n            : 0;\n    }\n\n    public bool DeleteStudent(int id)\n    {\n        var dcs = new DataCallSettings(\"DELETE FROM students WHERE id = @Id\");\n        dcs.AddParameter(\"Id\", id);\n        return _provider.Execute(dcs) > 0;\n    }\n\n    private void AddStudentParameters(DataCallSettings dcs, Student student)\n    {\n        if (student.IsNew) { dcs.AddParameter(\"Id\", student.Id); }\n        dcs.AddParameter(\"Name\", student.Name);\n        dcs.AddParameter(\"School\", student.School);\n    }\n}\n```\n\n## The conclusion\n\nOkay, 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.\n\nThis 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.\n\nUsing 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.\n\nThis 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.", "url": "https://wpnews.pro/news/build-a-database-connection-framework-in-133-lines-of-code", "canonical_source": "https://dev.to/nmiller15/build-a-database-connection-framework-in-133-lines-of-code-io8", "published_at": "2026-05-23 19:23:14+00:00", "updated_at": "2026-05-23 19:32:59.756671+00:00", "lang": "en", "topics": ["developer-tools", "open-source", "data"], "entities": ["Entity Framework", "ASP.NET", "SQLite", "SQL Server", "Postgres", "MySQL", "ChatGPT"], "alternates": {"html": "https://wpnews.pro/news/build-a-database-connection-framework-in-133-lines-of-code", "markdown": "https://wpnews.pro/news/build-a-database-connection-framework-in-133-lines-of-code.md", "text": "https://wpnews.pro/news/build-a-database-connection-framework-in-133-lines-of-code.txt", "jsonld": "https://wpnews.pro/news/build-a-database-connection-framework-in-133-lines-of-code.jsonld"}}