What is the difference between orm and ADO.net?

Question

I am reading a book, and she says: “If you create your own level of data access using ADO.NET to access your database, you will be minimally affected if the data schema exists or not. Using O / RM, your flexibility will be limited to the tool you use. " What is the main difference between ADO.NET and any other ORM?

Answer 1

ADO.NET provides ongoing access to data sources such as SQL Server and XML, and data sources provided through OLE DB and ODBC. Custom data exchange applications can use ADO.NET to connect to these data sources and retrieve, process, and update the data that they contain.

ADO.NET separates data access from data manipulation into separate components that can be used separately or in tandem. ADO.NET includes the .NET Framework Data Providers for connecting to a database, executing a command, and obtaining results. These results are either processed directly, placed in an ADO.NET DataSet for the user in a special order, combined with data from several Sources, or transferred between levels. A DataSet can also be used independently of the .NET Framework data provider to locally manage data in an application or retrieved from XML.

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

Object-relational mapping (ORM, O / RM, and O / R mapping tool) to computer science is a programming method for converting data between incompatible type systems in object-oriented programming languages. The result is a "database of virtual objects" that can be used from a programming language. There are both free and commercial packages that perform object-relational mapping, although some programmers prefer to create their own ORM tools.

Entity Framework and NHibernate are ORMs. This means that you do not work with SQL connections, commands, parameters - ORM does this for you and allows you to display the structure of your database in OOP mode: you can add, read, update, delete records in your database using objects in C #. You only need to correctly match your object with the database. Entity Framework built on ADO.NET and uses ADO.NET internally. SQL statements are generated by ORM. ORM

As a rule, access to the database without ORM is faster, but you must provide more lines of code. If you want to work with the database in OOP mode and write more readable code, you should choose ORM. It depends on your goals on what to choose.

There are micro ORMs (Dapper, BLToolkit) that allow you to write SQL queries and map parameters to object properties. Micro ORMs tend to have better performance than Full ORMs, but ADO.NET is still faster.

There are also some questions and answers on Stack Overflow: EF vs ADO.NET

Answer 2

• Along the way, I found out that developers hate working with DataSets and DataReaders
• The .NET platform defines a number of namespaces that enable interoperability with relational database systems. Collectively, these namespaces are known as ADO.NET.
• ORM stands for Object-Relational Mapper , which is designed to map an object to the relational world. As the name suggests, builds a relation / maps objects (model) to database objects(tables).
• ADO.NET was the traditional way to connect your application to the database. gave the developer full control over database operations, while ORM built on top of ADO.NET and uses ADO.NET implicitly.
• In short, using an ORM such as NHibernate, the Entity Framework makes life easier when mapping objects (models) internally is solved using ORM.
• When you use ORM , not everything is in your hands, since all requests are generated by ORM itself. Now we do not know whether these queries are optimized or not.

In cases where the performance of your application is the main task & absolutely critical OR in cases where you know that your application will become huge in the future, then it is recommended to use ADO.NET instead of the Entity Framework , because it makes your application heavy.

• The solution to this problem was Micro ORM as Dapper, BLToolkit . They provide the essence of what developers want - an easy way to map database operations to strongly typed classes.
• In some cases, LINQ support makes it even better. But the main advantage of some of these micro-ORMs is their raw speed.

Words of Wisdom:

1. Dapper just displays, but you need to code a lot, EF does a lot more, not just display. So EF will be slow.
2. I can also say that pure ADO.NET faster than Dapper , OLEDB faster than ADO.NET , and ODBC can be faster than OLEDB.
3. So if I am serious about performance, I would probably avoid ORM.