Difference between ADO.NET and Dapper

Question

What are the differences between Orms? When to use one and when to use the other? What are the disadvantages of each?

Answer 1

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

The . NET works with data providers. There is a Basic API that every application . NET will understand to access data sources, especially relational databases, since the model was designed for this type and source. Any database or other source can create a data provider by supporting this API and deliver the data in the best way possible to the .NET. On top of this API can be built Orms.

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

Some Orms are lighter and essentially do this, so they are called Micro Orms, and those that have a more sophisticated infrastructure giving other functionalities, probably implementing a repository engine, are Full Orms.

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 by default on . NET and has a minimum infrastructure and even some small functionality close to that of a repository, but in a very limited and somewhat problematic way. It is always a layer on top of the data provider and so is slower. If use badly it can be tragic. But the same goes for a Full ORM. In a way, it is even more ORM than the Dapper for offering extra facilities. It does not create a POCO object, but 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 has an incredible performance, beating ADO.NET. It has a simpler infra, and does only basic mapping and conversion without any extra mechanism, even a CRUD needs an extra (available). It is very fast, very simple, and only provides a deficiency of the data provider that does not have the same function of providing a data model. It creates a normal object.

Amazingly enough, Dapper tends to be more interesting because it is a technology created based on more realistic use and is something more modern. Although it provides less functionality, it ends up working better than ADO.NET for most cases. In general it is possible to create very simple and flexible applications with it, in addition to very performative.

Particularly I would only use ADO.NET if I’m used to it and don’t want to mess with anything else. Even its advantages end up being disadvantages in some points. Or I would use the pre-date direct, although the gain is minimal and the disadvantage ends up not compensating.

It is possible to 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’re doing to make 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 the hand or with the most flexible EF own tools or using Dapper or ADO.NET.

Remember that a Micro ORM will always use darlings of the database while a full ORM will use its own query language, in the case of EF LINQ to Entities (until it does not get what it wants and then goes to SQL as well).

Answer 2

ADO.NET

Not an Object-Relational Mapping (ORM).

According to the documentation:

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

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

Dapper

It is also not a Full ORM (complete ORM) itself. The documentation make that 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.

in free translation:

Dapper is an ORM?

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

Micro ORM x Full ORM

ORM is Object-Relational Mapper and works as consulting and creating objects, at runtime, between the client’s code and the relational database. Full Orms (Full Free Translation Orms) provide a number of powerful features such as object caching and queries, concurrency control, object-oriented query languages, etc..

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

Limitations (I will use the English term):

• 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 (batch)