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 back-end database. So, why do we 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 article describes a set of wrapper classes to make it simpler to work with ADO.NET. This article does not go into every line of code in the wrapper; it is intended as an overview of the functionality.)
A common task we face as developers is to take data from a database table and create a collection of entity objects. We have several methods to accomplish this task. You can build a DataTable or DataReader, loop through the rows, build a new object for each row, and write lines of code to transfer column data to each corresponding property. Another method is to use an object relational mapper (ORM) such as the Entity Framework, Dapper or NHibernate which performs these operations for you. Have you ever wondered how these ORMs build the collection? Well, wonder no more. This blog post will show you how it is done.)
While there are many programmers who use the Entity Framework these days for database access, there are still many who do not. Many programmers still use ADO.NET directly to perform standard CRUD logic. When you must use dynamic SQL to perform queries, it is very important to not let any SQL injection attacks through. This blog post shows you how to use parameters with dynamic SQL.)