It depends on the particular ORM, but here are some features that I think are fairly common:
You don't have to manually write SQL code to access your database. Instead you declare how your objects are mapped to the db and then create expressions like the one I showed above in your target language. This can speed up your development and give you some flexibility as well.
I think it is not uncommon for ORMs to have built-in caching that you can configure. That way you don't have to write a lot of your own custom code to deal with caching.
ORMs also usually support a transaction or unit of work. This again means you don't have to write as much custom code to deal with, say, multiple threads accessing the same entities. You don't have to write the code to deal with what these different threads will see. There are usually configuration options that allow you to make reasonable choices.
The basic point is that it is middleware code that allows you to do less work to get your code integrated with a database. You can certainly manage all of the persistence yourself using a lower-level library, but I think it is probably a good idea to use an ORM in many cases.
ohh okay! Can you explain more on what is ORM basically? I mean why would we need it?
It depends on the particular ORM, but here are some features that I think are fairly common:
The basic point is that it is middleware code that allows you to do less work to get your code integrated with a database. You can certainly manage all of the persistence yourself using a lower-level library, but I think it is probably a good idea to use an ORM in many cases.
ohh So ORMs are implemented really well we are just putting a layer over it. Thanks