I disagree a little bit with what they said there. Both are micro ORMs.

.NET works with data providers . There is a Basic API than the whole .NET application will understand to access data sources, especially relational database, since the model was intended for this type and source. Any database or other source can create a data provider based on this API and deliver the data in the best possible way to .NET. On top of this API can be built ORMs.

An ORM is a relational object mapper, that is, it creates an object based on relational model fields (this has been relaxed and other data access models can be used) from a database, and the object can be transformed into fields that will be updated in the database. An ORM nothing more than this. This is necessary not only because of the way each one is made up, but also because the typing of each one tends to be different and a conversion or adaptation may be necessary.

ADO.NET and Dapper are Micro ORMs. Entity Framework and nHibernate are full . Some of the Full ORMs tend to abstract the database, although this may not be as advantageous as it seems.

ADO.NET comes standard in .NET and has a minimal infrastructure and even a small functionality next to a repository, but rather limited and somewhat problematic. It is always a layer on top of the data provider and so is slower. If using it badly it can be tragic. But the same goes for a Full ORM. Of a certain form, it is even more ORM than the Dapper by offering extra facilities. It does not create a POCO object, but it creates an object that is accessed through a data collection syntax. You can create an extension that delivers a POCO object if that's what you want.

Dapper, created by the company that owns this site, is also a layer on top of the data provider and performs amazingly by beating ADO.NET. It has a simpler infra, and only does the basic mapping and conversion without any extra mechanism, even a CRUD needs an extra (available). It is very fast, very simple, and only supplies a deficiency of the data provider that does not even have the function of providing a data model. It creates a normal object.

As incredible as it seems, Dapper tends to be more interesting because it's a technology built on more realistic use and something more modern. Although it provides fewer features, it works better than ADO.NET for most cases. In general it is possible to create very simple and flexible applications with it, as well as very performative.

Particularly I would only use ADO.NET if I am used to it and do not want to mess with something else. Even its advantages end up being disadvantages in some points. Or I would use the direct data provider , although the gain is minimal and the disadvantage does not compensate.

You can use both together, including with EF. But the ideal is not to mix so much. If you do you need to be very aware of what you are doing to take advantage of the best of both and not create new problems. In fact some people use EF where it can and when it gets too complicated to use it goes more in hand or with EF's own more flexible tools or using Dapper or ADO.NET.

Remember that a Micro ORM will always use queries from the database in which a Full ORM will use its own query language, in the case of EF LINQ to Entities.

ADO.NET

It is not an Object-Relational Mapping (ORM).

According to documentation :

  

ADO.NET is a set of classes that expose data access services for .NET Framework developers.

     

ADO.NET provides a rich set of components for creating distributed and data-sharing applications. It is part of the .NET Framework, providing access to relational and XML application data. ADO.NET supports a variety of development needs, including creating front-end database clients and middle-tier business objects used by applications, tools, languages, or Internet browsers.

Dapper

It is also not a Full ORM itself. The documentation makes this clear:

  

Is Dapper an ORM?   Yes and no! People are still arguing about it. Dapper has earned the title of king of the C # Micro ORM but is considered by multiple people as a simple object mapper for .NET.

free translation:

  

Is Dapper an ORM?

     

Yes and no! People are still arguing about it. Dapper won the title of King of C # Micro ORM, but is considered by many people as a simple ( NT: simple in the sense "does just that ..." ) object mapper for .NET .

Micro ORM x Full ORM

ORM is Object-Relational Mapper and functions as a query and creating objects, at run time, between the client code and the relational database. Full ORMs provide a number of powerful features such as caching objects and queries, concurrency control, object-oriented query languages, etc.

The Micro ORM is basically a mapper that creates objects based on the query to the database. They abstracted much of the ORM's resources to gain in performance.

Limitations (I'll use the terms in English):

• Second Level caching;
• Lazy loading;
• Identity tracking;
• Change tracking;
• Rich mapping model that supports multiple data sources;
• unit-of-work API - Essentially a SubmitChanges () method that apply batch modifications