ADO.NET EF v LINQ to SQL (take 3)

I come in peace.  This is a post to continue my series about my opinions and thoughts on the issue.  If you haven’t I suggest you go back and read Part 1 and Part 2.

So I’ve been working on a MVC application for a friend of mine and his business.  When I had the meeting with them I originally thought that for the purpose of a retail storefront I would go with ADO.NET EF to give it a really fair trial in the eyes of the jury.

So I started off making some POCO objects so that if I decided to change things up I could do so without having to re-do my whole DAL/BLL.  Shortly after I finished the database setup and the original POCO creation I noticed ADO.NET EF doesn’t support POCO with any ease… fannnnntastic.  After an hour or so of playing with my Rubiks cube I went back to coding, using ADO.NET EF’s code generated objects.  I started to stub out the controllers and write code for adding/removing entities.  It came time to deal with a Product/Category relationship and I realized ADO.NET EF had hidden the CategoryID field on the Product object.  After some digging around I found out you can expose it with some pain and anguish but you can’t even use it to query with.  Mot only that, since I couldn’t even use the CategoryID property on the Product object I decided I would just query for the Category and set the Category property on the Product object.  Guess what – if you have a Product Repository and a Category Repository, you can’t query a Category from one and use it in an object queried from another context.

Here I am, with some code generated objects that I can’t access direct properties of.  I decided to persevere and continue because I really did want to get ADO.NET EF a fair fight.  Knowing I couldn’t access FK properties on objects nor could I set them without having them come from the same context I thought I would try out Stored Procedures… only to find out I couldn’t map them in ADO.NET EF.

At this point I decided to stop, I had wasted almost an entire day moving backwards with productivity for something that should’ve been relatively easy.  They say ADO.NET EF is conceptual mapping which in my opinion should be it would be easier to map things the way you want to without having to bend over backwards, WRONG.  I’ve read that the LINQ to SQL guys have merged with the ADO.NET EF team to bring over some of the features (read: requirements) LINQ to SQL supports.  Hopefully this turns out well.

I really hope those LINQ to SQL guys help out the ADO.NET team because right now ADO.NET EF was a waste of my time.  When v2 comes out if half of these problems still exist I think I’ll be moving to Ruby and Ruby on Rails.  There is a large base of .NET developers moving to the RoR platform and tons of support with books and articles.  We can only hope with that with the new light ASP.NET MVC has shed on ASP.NET that Microsoft will seize this opportunity to show they can do their consumers right.


Comments have been disabled for this content.