asp.net - Is ADO.NET in .NET Core possible?

Question

I would like to use the most recent versions of ASP.NET Core, because I want to create a set of Web APIs with it. However, the tutorials that I found are strongly focused on Entity Framework. I can't use that because I already have a "legacy" database, so a Code-First approach is not an option.

My idea is to use ADO.NET connections to my database, however I don't know if System.Data.SqlClient is available in a ASP.NET Core project. I already found that is available when I use a .NET Framework project template but is it still available in a .NET Core project?

Answer 1

The existing SqlConnection and other related connections still exists within the System.Data.SqlClient namespace and should work as expected using the full framework or .NET Core.

You'll just need to add the appropriate references and using statements to include it such as through the System.Data.SqlClient namespace as seen below in your project.json file :

and then call it via the syntax you are accustomed to :

using(var connection = new SqlConnection("{your-connection-string}"))
{
      // Do work here
}

So as long as you have a valid connection string to connect to your existing legacy database, you should be just fine.

Regarding ORM Usage

I also found that some people are using Dapper, a Micro-ORM replacement for Entity Framework, apparenty more flexible. It is there any advantages of using it instead ADO.NET?

These ORMs (object-relational mappers) are handy and often powerful tools that can more easily map your existing database data to specific classes and objects, which can make them easier to use (as opposed to iterating through a data reader, parsing each of your rows and building each object manually).

As far as performance goes, it ultimately depends on what you are going to be doing with your queries. ADO.NET will generally be the fastest as it a bare-bones connection to the database, however in some scenarios Dapper can actually beat it out. Entity Framework, while very useful, generally trails behind in performance, simply because it is such a large ORM.

Again - it ultimately depends on what you are doing, but all are viable options.