EF4 In real life and using Code Only – Yes We Can ?

Hi all it's been a while but i didn't have anything interesting to write about. Lately I was involved in a process of choosing the technology used in Data access infrastructure of new application, and let's just say it wasn't a simple decision but a fascinating one.

General 

The decision process was interesting and long, the dilemma was reduced at the end to decide between two ORM solutions: NHibernate and Entity Framework 4 – EF4 (I'll give some details below). Finally we decided to go with EF4. The risky part in this decision is that EF4 is only lately released (with vs 2010 RTM) and we don't have any known enterprise application using it in production.I Just want to add into considerations that the application Client is developed at Silverligth 4.

Special requirements – Code Only.

The specific application had one additional special need: defining the DB mapping in runtime which means do not use a static edmx file. The solution was to use the Code Only feature – which is currently part of CTP (Microsoft ADO.NET Entity Framework Feature CTP 3) and not part of the release. This issue was added to the danger factor – can we use it to define a complicated model – does it answers our needed scenarios and is it good enough from performance point of view.

EF4 vs NHibernate

There is a lot to say in this section but I'll be brief.

First NHibernate has many advantages over EF4:

• Has more fine tuning abilities – scalability and performance.
• Is very mature – works for years in enterprise applications.
• Has more features.
• More Extendable – Open Source.
• Supports more DB types out of the box.

So why to choose EF4 you ask. Well for my specific needs, EF4 is more suitable from the following reasons:

• EF4 is more suitable for working in N-Tear architecture:
  • It has disconnected out of the box solution - the Self Tracking.
  • In order to use NHibernate for N-Tear you may need to use DTO because: working N-Tear with NHibernate is not straightforward especially with silverligth for example the many to one navigation property are defined in POCO as interface and the strong but complex lazy loading capabilities of NHibernate are not suitable for N-Tear when your entity is disconnected from the session.
• EF4 is more easy to start working with – you have the model designer and code generation items – and it all comes out of the box (NHibernate has some similar solutions but they supply only part of the features EF4 gives – comes out of the box in VS 2010) .
• EF4 is Microsoft – we cannot ignore this fact. We develop in a Microsoft environment, the .Net framework is evolving (LINQ, Dynamic ,Generics,Covariance …) it makes sense that Microsoft will evolve EF as well and do it more easily because it's all develops in the same organization.

EF4 problematic issues

while working with EF4 I encountered some problems, some of them are pretty critical.

• Code only

Using the code only was a must because of my special needs (as described above). Although using CTP I must say the work was quite smooth and very intuitive. The problems I encountered were not related to the code only feature specifically, but to EF4 in general. The downside was the lack of documentation and information in general. the best information source I found was the All-In-One Code Framework from codeplex and the ADO.NET team blog.

The inheritance TPH (table per hierarchy) issue

This issue was very surprising for me, I tried to define TPH inheritance with code only (using the example from All-In-One Code Framework), then I got strange exception ("InvalidException previous cannot be null"). After a short investigation I discovered that the reason was that the derived classes and the base class weren't located in the same assembly. I checked it without code only feature (with simple edmx file) and the result was the same – an ugly exception. Please tell me if I am doing something wrong or missed something because if not it's a bug and a big one – most likely that in enterprise applications there will be a separation between the base classes and derived classes. So I did a workaround (too ugly to mention) for this issue, but I'm open for you suggestions how to deal with this problem.

• The inheritance TPT (table per type) issue

This is a known issue of Entity Framework (from EF1 and still not resolved in EF4). When you define a very common inheritance strategy: each derive is stored in separated table. EF fully supports this strategy but the queries it produces when querying the model is "evil". evil meaning very long (in some scenarios it can cause exceeding the query string limit if we have many inheritances) and has very poor performance – union of left joins of all the derived tables. EF also supports Hybrid mapping meaning define TPT and gives a condition for each specific type (called discriminator in NHibernate) but when producing the Query EF still generates these "evil" queries.

I must say this issue is critical and Microsoft should attend it as soon as possible because currently it's is one of the biggest obstacles when using EF in enterprise applications.

The Solution is to avoid working from the base class when querying, meaning add and delete should be done from the base (we don't really have other options), but when querying work only from the derived use the syntax:

from user in context.Users.OfType<SpecificUser>();

this will generate an efficient inner join query.

* If you need to query your model from the base type consider using TPH or even consider not using EF4 because currently there is no good solution for this issue.

Summery

Having said that, what is the answer to the question in the title: yes we can ?

well the answer is still not clear so I'll say: at this early point it looks like yes :-). I'm sure all the problems I mentioned will be eventually solved by Microsoft, but for now it works (with some workarounds).In my DAL infrastructure – abstraction layer above EF4 (using Repository and UnitOfWork pattern) I use EF in two ways:

• Using code only context.
• Using edmx file - The usual static model.

I'll update you as the application will get more mature. That's all, waiting for your comments and\or suggestions.

Cheers, Offir.