What Is Ado.Net

What is ADO.NET?

Loosely, in easy speak

ADO.NET
is a library of commands and objects that allow your application to talk to a database. If you have used ADODB in VB6/C++ then ADO.NET is the .net (vb.net/C#) equivalent. ADO.NET provides you with objects such as a connection object, dataset and datareader objects.

ADO.NET provider
Think of a provider like a graphics or device driver. Each time you put a different graphics card inside your computer you need to have a new graphics driver to get your graphics card to work at its best. The same is true for ADO.NET, for each different type of database you connect to (e.g Microsoft Access, Microsoft SQL Server, MySQL, Sybase, Oracle etc.) you will need a different ADODB.Net provider. A handful come as standard (for example, the provider for SQL Server)

SQLite.NET
Is a database server or RDBMS - think of it as a lightweight competitor to SQL Server or MySQL.

ADO.NET 2.0 Provider for SQLite
Combine the last two answers!

SQLite Entity Framework and SQLite Entity Framework provider
This is a whole different subject completely. Look up Object Relational Mapping

What is the difference between an orm and ADO.net?

ADO.NET provides consistent access to data sources such as SQL Server
and XML, and to data sources exposed through OLE DB and ODBC.
Data-sharing consumer applications can use ADO.NET to connect to these
data sources and retrieve, handle, and update the data that they
contain.

ADO.NET separates data access from data manipulation into discrete
components that can be used separately or in tandem. ADO.NET includes
.NET Framework data providers for connecting to a database, executing
commands, and retrieving results. Those results are either processed
directly, placed in an ADO.NET DataSet object in order to be exposed
to the user in an ad hoc manner, combined with data from multiple
sources, or passed between tiers. The DataSet object can also be used
independently of a .NET Framework data provider to manage data local
to the application or sourced from XML.

ADO.NET is a layer that allows you to connect to DB and modify it using SQL connections, commands, parameters. ADO.NET MSDN

Object-relational mapping (ORM, O/RM, and O/R mapping tool) in
computer science is a programming technique for converting data
between incompatible type systems in object-oriented programming
languages. This creates, in effect, a "virtual object database" that
can be used from within the programming language. There are both free
and commercial packages available that perform object-relational
mapping, although some programmers opt to construct their own ORM
tools.

Entity Framework and NHibernate are ORMs. It means that you do not operate by SQL connections, commands, parameters - ORM does it for you and it allows to map your database structure in OOP manner: you can add, read, update, delete records in your DB using objects in C#. You need only map your object to DB correctly. Entity Framework is built on ADO.NET and it uses ADO.NET inside. SQL statements are generated by ORM. ORM

Generally, access to DB without ORM is faster, but you should provide more lines of code. If you want to operate your DB in OOP manner and write more readable code you should choose ORM. It depends on your purposes on what to choose.

There are Micro ORMs (Dapper, BLToolkit) which allows you to write SQL queries and map parameters to object properties. Micro ORMs, in general, have better performance than Full ORMs, but ADO.NET is still faster.

Also, there are some questions and answers on StackOverflow: EF vs ADO.NET

What is ADO.NET

Think of Ado.net as a managed library that provides all the classes and functionality you need (and may use) to access external data sources. That's the most simplest way of thinking of it. But since it's not a separate library (because it's included with the .net library) people tend to be confused. We could say it's a library inside .net.

A more thorough explanation can be found on Wikipedia.

Stored procedure is part of a particular data store. Ado.net gives you the ability to call these stored procedures in a standardized way.

An example from MSDN

using (SqlConnection connection = new SqlConnection(connectionString))
{
    // Create the Command and Parameter objects.
    SqlCommand command = new SqlCommand(queryString, connection);
    command.Parameters.AddWithValue("@pricePoint", paramValue);

    // Open the connection in a try/catch block. 
    // Create and execute the DataReader, writing the result
    // set to the console window.
    try
    {
        connection.Open();
        SqlDataReader reader = command.ExecuteReader();
        while (reader.Read())
        {
            Console.WriteLine("\t{0}\t{1}\t{2}", reader[0], reader[1], reader[2]);
        }
        reader.Close();
    }
    catch (Exception ex)
    {
        Console.WriteLine(ex.Message);
    }
    Console.ReadLine();
}

You can see the use of Ado.net classes:

• SqlConnection
• SqlCommand and
• SqlDataReader

So Ado.net has all these provided for you, so you don't have to reinvent the wheel every time you'd like to access external data sources (relational data bases, services etc.).

What is ADO.NET?

ADO.NET is a .NET technology designed to make writing code against the database more easy.

It's not a database (SQL Server is a Database server), it's a tool used to access a database. ADO.NET last incarnation comes with "Entity Framework", an Object Relational Mapper (an other tool designed to make the developper life easier too)

Immitating an ADO.NET design in Entity Framework Core

The connection between Products and Categories - no problem, just an ICollection property in each of the two responding classes. Entity Framework immediately created a CategoryProducts junction table.

If this works, then you are using EF Core 5.0+ which added support for many-to-many relationship with implicit join entity, as can be seen, creating such relationship is quite easy.

But your CategoryCategories represents exactly the same type of relationship, with the only difference that both related ends are one and the same entity.

So how you create such relationship between two entities? You do that by adding 2(!) collection navigation properties in each related entity:

class Product
{
    public ICollection<Category> Categories { get; set; }
}

class Category
{
    public ICollection<Product> Products { get; set; }
}

(side note: the type of the property setter (public, internal, protected, private) doesn't matter for EF Core).

Which leads us to the answer of question how do you define such relationship between the same entity? Well, exactly the same - by adding 2(!) collection navigation properties in each related entity, which in this case is one and the same:

class Category
{
    public ICollection<Category> ParentCategories { get; set; }
    public ICollection<Category> ChildCategories { get; set; }
}

And that's it. No need of explicit CategoryCategory entity. EF Core creates automatically something like this

migrationBuilder.CreateTable(
    name: "CategoryCategory",
    columns: table => new
    {
        ChildCategoriesId = table.Column<int>(type: "int", nullable: false),
        ParentCategoriesId = table.Column<int>(type: "int", nullable: false)
    },
    constraints: table =>
    {
        table.PrimaryKey("PK_CategoryCategory", x => new { x.ChildCategoriesId, x.ParentCategoriesId });
        table.ForeignKey(
            name: "FK_CategoryCategory_Categories_ChildCategoriesId",
            column: x => x.ChildCategoriesId,
            principalTable: "Categories",
            principalColumn: "Id",
            onDelete: ReferentialAction.Cascade);
        table.ForeignKey(
            name: "FK_CategoryCategory_Categories_ParentCategoriesId",
            column: x => x.ParentCategoriesId,
            principalSchema: "SO14",
            principalTable: "Categories",
            principalColumn: "Id",
            onDelete: ReferentialAction.Restrict);
    });

If you don't like the generated table/column names, they are all configurable through fluent API. You can even create and map explicit join entity if you like, and still use the benefits of the so called "skip navigations".

But the two collection navigation properties are the bare minimum, and are the thing which makes the EF Core approach much easier.

ASP.Net ado.net problem EDMX Entity Framework

The EDMX is a representation of the model - but you have to run the .tt files in order for them to analyze your EDMX to create the model.

UPDATE: The .tt file should be under the .edmx file in your Solution Explorer.

To do this, right-click the .tt and chose to Run (can't remember exactly what the command is) but it will execute your changes to the EDMX and create the various .cs or .vb classes for you. In your case, it's the Employee.Context.tt file that you need to run/execute.

Be careful if you change the generated .cs or .vb files that are created, as if you re-run the .tt file, it'll drop and recreate your code, potentially losing any customisations.

UPDATE: I've found you this really good explanation of each stage which might help.

Hope this helps.

---

Related Topics