I still remember the days when we were spending quite a lot of time on working with relational databases rather than just focusing on solving business problems; those days are definitely gone. To elaborate, let's jot down the issues we had before ORM:
- Data access layers were not portable, which made it hard to change from one platform to another.
- There were no abstractions, which forced us to write manual mapping between objected-oriented objects and data entities.
- Vendor-specific SQL statements, which requires knowledge to port between different RDBMS systems.
- Relied heavily on triggers and stored procedures.
The entire product development process shifted towards tools and open source platforms, and even Microsoft took that path from .NET Core onward. If we keep spending time on writing code which could be achieved through tools, we might end up looking like cavemen.
The Entity Framework was created to address this concern; it was not introduced with the initial .NET framework but rather was introduced in .NET Framework 3.5 SP1.
If we look closely, it was obvious that the .NET team built it for the following reasons:
- To minimize the time spent by the developers/architects on stuff like abstractions and the portable data access layer
- So that the developers do not require vendor specific SQL knowledge
- So that we can build object-oriented business logic by eradicating triggers and SPs
We will cover the following topics here:
- Prerequisites
- Creating a new project
- Installing Entity Framework 2.0
- Data models
- Database context
- Registering the context in services (.Net Core DI)
- Creating and seeding databases
- Performing CRUD operations