Before I explain myself, I need to identify the common patterns I think are necessary in any application that needs to persist data:

EF works to simplify the development for database dependent applications by removing the redundant work involved in each project. Namely, the below highlighted tasks:

What is so bad about Entity Framework?

1. Most developers do not know to optimize database operations. EF creates a sandbox so that they may do whatever the hell they want with the data. This will drive any DBA crazy when they are asked to make optimizations.
2. With 99% confidence, I believe that most of the .NET framework code is bug-free (or has yet to become a problem for me). Knowing this, we can believe that our EF SQL queries are probably legit. But isn’t it important to test our queries themselves through unit tests? The ability to unit test our own data access methods without requiring an active database (in-memory or XML defined?) is a necessary feature.
3. Consequently, the application is fully aware of the ties to the EF and cannot be tested without. Persistence ignorance support is necessary so that developers are not forced to implement additional interfaces or provide unnecessary references.
4. Developing N-Tiered Applications with EF is difficult. Reattach objects into the data context after client modifications requires too much work.
5. Lazy loading improves performance, but excess code is needed to check if a related set is loaded. If it is not loaded, additional code is required to perform the operation. Consequently, it could make database operations unnecessarily chatty.

I am only able to list five points about what is bad about the EF, after working on it for 8 months. In that time I have managed to work around two of the five issues with ADO.NET Data Services (unit testing data access methods with a mock implementation and creating N-Tiered applications). Performance issues have cropped up that I am 100% confident would not exist if custom code had been written to manage data access.

So what is the ‘Entity Framework Balloon’?

Someone once provided this analogy to me.

If our project were a water balloon, each development task would have its own piece of space. The introduction of EF attempts to shrink the cost/time to do the redundant tasks by compressing that side of the balloon. But the other tasks have to go somewhere else, and their piece just gets bigger and requires more effort in the long run.

There always seems to be a new tool for the job. EF obviously serves its purpose, but it fails at making everything as easy as it seems.

.NET 4 with the new Entity Framework

Looking ahead, the ADO.NET Team Blog has focused on a list of concerns for the next version of EF.  They are focusing on improving:

1. Enabling settings to make development simpler such as lazy loading, eager loading, and stored procedure mapping.
2. Improving the readability of the generated SQL.
3. Persistence Ignorance support, allowing you to write POCO and later tie them to Entity Framework or another Data Provider.
4. Better N-Tier Support allowing the serialized entities to include their own change tracking properties.
5. Model-First and Code-Only development!
   

    

   Entity Framework Reading List:

   Anti-Patterns to Avoid in N-Tier Applications
   The Entity Framework in Layered Architectures
   What’s New and Cool in Entity Framework 4.0

The MS SQL data type, uniqueidentifier, does not have a counterpart in Oracle. In the past it was easy to make the column CHAR(36), the max string length of a GUID. I was not in a situation to do this as we were dealing with the Entity Framework against Oracle. 

Entity Framework is compatible with SQL Server out of the box and translates the uniqueidentifier column to GUID type. This is not the case for Oracle. The use of a third party adapter, dotConnect for Oracle, is required. This provider requires that the storage data type for GUID be RAW(16).

What’s the problem with RAW(16)?

GUID representation

{922B0A87-7A88-DE11-BBA7-0AEA0522E79F}

RAW(16) representation

870A2B92887A11DEBBA70AEA0522E79F

As if it was not tough enough already to read and write a GUID. Now it is represented differently in Oracle!!??

The best solution that I discovered to get around this was through the use of a handy GUID Converter. I don’t know how many times I have relied on this to help me out.