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

Question

I am reading a book and it says : "if you will create your own data access layer by using ADO.NET for access into you database, you will be minimally affected whether the data schema exists or not. If however you are using an O/RM, your flexibility will be limited by the tool you use". What is the major difference between ADO.NET and any other ORM?

Solution 1

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

Solution 2

• Along the way, I have learned that developers hate working with DataSets and DataReaders
• .NET platform defines a number of namespaces that allow you to interact with relational database systems. Collectively speaking, these namespaces are known as ADO.NET.
• ORM stands for Object-Relational Mapper which is to map an object with a relational world. As the name suggests it builds a relation / maps objects (model) to database objects(tables).
• ADO.NET was the traditional way to connect your application to a database & gave the developer entire control over the database operations whereas ORM is built on top of ADO.NET and uses ADO.NET implicitly.
• In short using an ORM like NHibernate, Entity Framework makes life simpler where mapping of objects(models) is taken care of internally by the ORM.
• When you use an ORM not everything is in your hands since all of the queries are generated by the ORM itself. Now we don't know whether those queries are optimized or not.

In scenarios where performance of your application is a primary concern & absolutely critical OR in scenarios where you know that your application will grow huge in mere future then it is advisable to use ADO.NET rather than Entity Framework because it makes your application heavy.

• The solution to this was Micro ORM's like Dapper, BLToolkit. These provide the esssence of what developers want - an easy way to map Database operations to strongly typed classes.
• LINQ support in some makes it even better.But the main advantage of some of these Micro-ORMs is its raw speed.

Words of Wisdom:

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

Comments

[Urasquirrel]

If I'm not mistaken you can also create an adapter pattern so that you can use both. It's an extra step, but might save you heartache later. Do you have any input on this?