1. Why Bother?

Well, okay. Maybe it’s not quite a battle for the heavyweight championship of the world. But with relational database theory on one side and object-oriented analysis and design on the other, you can have a fight on your hands. Computer scientists call it the impedance mismatch, and if you’re the poor programmer in the middle, it can get ugly. At best, you’ll spend a lot of time swapping between one mind-set and the other—because they really are different ways of thinking about a problem—and at worst, you’ll find yourself writing a bunch of tedious, error-prone code to translate your data between the paradigms.

If you’re in that position, or think you might be there in the future, you’ve come to the right place. This is exactly the problem that Entity Framework is designed to address.

Understanding how Entity Framework does its magic is easier if you have a basic understanding of the paradigms it bridges, so we’ll start in this chapter by taking a look at each side. But first, we’ll take a quick look at all the bits and pieces that make up an Entity Framework solution. There are a lot of moving parts, but don’t panic, we’ll get it sorted out as we go along.