Ef core: What is an ORM and why ef core?

This blog post is an intro to entity framework core and the underlying concepts. It will be the entry point for the recipes on this topic.

We will look into the concepts of an ORM, what it is exactly and how it helps us to develop better applications.
With this in mind we will then look at the general ideas that entity framework incorporates.

Be aware that we will not look into a deep analysis of benefits and drawbacks of an ORM. We simply want to explore with this recipes how and why we should use ef core in the first place.

For drawbacks/benefits analysis see this and other sources:

• Dapper vs entity framework core
• Vietnam of computer science
• Benefits & Drawbacks as discussed on SO

So with this little disclaimer let us start the overview.

Why

First let us ask why wants to use an ORM in the first place.
And no it is not to get around learning SQL and database design!! You absoulutely positvely need to have at least intermediate skills in relational databses to become an effective software engineer.

See also my recommendations on skills to become an efficient good software

But what possible reasons could instead exist?
First of all the access to the database will be easier, because ef core will handle the connections, pooling and other related topics of administrative areas.

Secondly we will see when we look at migrations, that you have way better maintainability with your business entities represented in the database, if designed apropriately that is, you can benefit from type safety in your application.

As you well might know, there is the so called object relational impedance mismatch.
This will be bridged by entity framework for you. This means it also will help you avoid repetitive tasks like accessing the database and also writing mapping code from database relationships based on foreign keys to the inverted relationship on object oriented models.

You also do not need to write Insert, Update, Delete and Select statements for each table on your own, even though this still might be the case if you embrace the repository and unit of work patterns.

With migrations you can also let ef core generate the database for you or generate some scripts that will help you to do so.

At another level ef core helps you, if configured correctly, to avoid sql injections on every level.

So those benefits can all be subsumised with extremely improved maintainability and ease of development.

Another one is that it helps you to keep up the single point of truth principle. This means your database will be changed at one place in the code and this one place only, which will help tremendously reduce the complexity in your application.

Also you can quite easily change the database provider your application uses by changing the ef core database provider. (if this should ever be the case). This is not always true, for example from sqlite where the context needs to be a singleton for the reason that sqlite only allows for a single connection and other little differences, that are inherent to the so called SQL “standard”.

On the drawbacks side, you will get obviously some performance hits by using something that does so much magic for you.
But if there might be some performance issues, you can still improve on that later. Remember:  

Premature performance optimization is the root of all evil. 

With the mentioned repository pattern you can also encapsualte the handling of your business entities and improve the performance at any time by simply changing ef core to raw sql queries for example.

Another drawback is that you need to learn a new framework. Which probably will benefit and pay off over the long run, because it is the standard framework for ORM in dotnet core (even though there are others like Dapper

With learning a new framework there comes struggle and the misuse of it, which maybe could be counted as a drawback.
But when you follow this recipes and really lean into ef core it will be a really helpful tool to have in the future, especially for asp.net core backend applications like WebApi´s.

With this we come to why ef core and not another ORM.

1. It integrates very well with sql server and other microsoft and ms related technologies (dotnet core, autofac, and so on)
2. The initial setup is very easy to do
3. High level of control via the fluent api
4. Build the database by code first approach (allows for domain driven design)
5. If you know LINQ you mostly good to go for database queries as ef core utilizes the IQueryable interfaces a lot.
6. ef core has a async first approach which integrates very well with the asyn/await and TPL of dotnet core
7. The migrations concept of ef core leads to a source controlish thing for your database as well as a single point of truth for the database when used correctly with migrations only (no direct changes on the database itself)

In the wake of the next posts we will deeper dive into the different concepts of entity framework and how they are applied.