Programming Articles

In the last two articles (Simplifying ADO.NET Code in .NET Core: Part 1 and Part 2), you learned how to retrieve data using a set of wrapper classes around ADO.NET. The code you wrote was about the same lines of code you might write when using the Entity Framework. In this article, you're going to build the appropriate methods to modify data in a table, perform transactions, validate data using data annotations, and add exception handling.

In the last article (Simplifying ADO.NET Code in .NET Core: Part 1), you wrote code to simplify ADO.NET and map columns to properties in a class just like ORMs such as the Entity Framework do. You learned to use reflection to make creating a collection of entity objects from a data reader and take advantage of attributes such as [Column] and [NotMapped]. In this article, you're going to refactor the code further to make it even more generic. In addition, you'll learn to get data from a view, get a scalar value, handle multiple result sets, and call stored procedures.

When developers think of how to access data, many use the Entity Framework (EF), Dapper, NHibernate, or some other object-relational mapper (ORM). Each of these ORMs use ADO.NET to submit their SQL queries to the backend database. So, why do many developers use ORMs instead of just using ADO.NET directly? Simply put, ORMs allow you to write less code. If each of these ORMs are simply wrappers around ADO.NET, can't you write your own wrapper to cut down the amount of code you need to write? Absolutely! This series of articles shows you how to create a set of reusable wrapper classes to make it simpler to work with ADO.NET in .NET Core.