Spent some time researching Entity Framework.

Before…
A data access layer.

After…
A data access layer. An ORM.

Entity Framework is a sexy easy to visualise solution that tends to make my life easier as a OO programmer when dealing with complex data. I don’t have to faff around with setting up and accessing data. Yay Microsoft :)

Entity Framework is sexy.

Some quick things I love about entity framework.
1. Intellisense & Type safety.
3. Database connectivity and SQL script encapsulation.
4. Sexy model designer space.

ORM. Object Relational Mapper. Entity Framework is an ORM. Entity Framework is one of many well know Object Relational Mappers. NHibernate, Subsoniq, Castle ActiveRecord, LLBLGenPro.

Interestingly. A NoSQL database like MongoDB doesn’t rely on an ORM. A NoSQL database doesn’t have SQL. So there is no need to convert an object graph query into SQL.

What about LINQ to SQL?
Well. LINQ to SQL is another ORM in the MS stack. ADO.NET is another alternative ORM. Entity Framework is the future of MS ORM investment.

What is LINQ to Entities?
LINQ to entities is just a regular part of the process of using EF. You’ve got entities. You write LINQ to traverse to object graph to create a Command Tree which is then converted into SQL.

Open Source
What? Entity Framework is an open source product? Yes. In 2012 Entity Framework 5 was made open source. The developer community are involved in development and enhancement. the Microsoft team are responsible for committing those changes. Since EF 6, the core of EF has been stripped out of .Net. It’s now a nuget package!

What is a Command Tree?
A command tree is used to generate SQL. When you use EF you tend to use LINQ to retrieve data through the inspection of a series of objects. This inspection is converted into a Command Tree which is then converted into SQL by EF.

this
…
context.Customer.Where(c => c.FirstName == “Robert”);

becomes
…
FROM [dbo].[Customers]
WHERE N’Robert’ = [Firstname]

In Memory Objects

When dealing with EF there are two things to consider. Firstly – how is my query or change going to affect the DB. Secondly, and perhaps more importantly, how is my request going to affect the way EF managers these data objects in memory at run time.

For example. With EF. When you create a new object and then add it to the EF context it doesn’t persist that change to the DB. To ensure that object is stored and safe the developer is required to run a ‘SaveChanges()’ method on that object.

EF Workflow
This seems to make no sense. I think it’s just a language guide. A way to get started. There are 3 distinct approaches.
1. Database First. Use VS entity framework design to reverse engineer the database into a model. An edmx file. This will create classes. This will create a context that is used to manage those classes.
2. Designer First. Start from scratch in a blank model.
3. Code First. Or build some classes and then build the designer model and the associated tables from the top down.