Entity Framework 4.0 ​dissapointm​ent

This could be my ineptitude but I have now wasted nearly two days trying to upgrade a Linq to SQL project to EF 4.0.

What I am finding out is that I am writing far more code not less for starters when dealing with related tables. I know Microsoft will say that they only employ the best of the best, and will have justifications for things like the IRelatedEnd. In linq to SQL you have an AddRange for your EntitySet, in EF 4.0 you only have an add method, so you have to create your own for loop each and every time. The EntityCollection is a pain in the backside to use in nested  table scenarios .

I am that annoyed this morning, I have just reluctantly resolved to go back to a previous build before EF 4.0. I don't care what anybody says, but the EF object model is horrible, no in fact it is atrocious. If you are a new user then you will learn it because you do not know any better, but be warned. EF 4.0 uptake will not be as rapid as you might think. I best stop writing in case expletives start to present themselves as worthy of communicating my fury, but it is difficult to be or sound objective when you are as annoyed as I am with EF 4.0. I will never get the time back

In fact I think where things went wrong, was when Anders Hejlsberg and the C# design team left the Linq to SQL project. Things went from a lovely abstraction that was a little limited to something that is not so limited but is an absolute pain to use. I am now going to consider using nHibernate as EF 4 is a dissapointment.

nHibernate will have the same pull-out-of-hair type stuff you get with EF.

All frameworks have those.

Maddus Mattus said:

nHibernate will have the same pull-out-of-hair type stuff you get with EF.

 

All frameworks have those.

I second that.

However, EF4 beats NHibernate in these aspects.

(1) No need to manually create NHibernate bindings.

(2) Compile-time error checking of your LINQ syntax compared to "string" based HSQL in NHibernate.

(3) Really nice Visual Studio Tooling support.

If you don't mind spending a lot of time on those, go ahead.

But IMO, EF4 is a much-better release than EF1.

It just takes some time to get used to it.....and a little patience.

stun said:

Maddus Mattus said:

*snip*

I second that.

 

However, EF4 beats NHibernate in these aspects.

(1) No need to manually create NHibernate bindings.

(2) Compile-time error checking of your LINQ syntax compared to "string" based HSQL in NHibernate.

(3) Really nice Visual Studio Tooling support.

 

If you don't mind spending a lot of time on those, go ahead.

But IMO, EF4 is a much-better release than EF1.

 

It just takes some time to get used to it.....and a little patience.

I know you guys are probably right, and I need to grow up and stop having tantrums, but I have a pretty complex bit of code using Linq to SQL, with primary keys that are auto-generated.

I choose Linq to SQL because of posts like this. Open up EF 4.0 and guess what, still no auto-generated keys.The key win with EF 4 is that it can reflect against SQL compact so my ORM is generated easily. This gets painful with Linq to SQL using sqlmetal.exe, manually editing the  ORM, but it allows for auto-generated keys. I cannot fathom for the life of me why the EF team have been inconsistent in this regard. This is how every other database and ORM on the planet works.

My key dislike is that the syntax is horrid, and it requires more steps not less to achieve the same thing in in EF 4.0 than Linq to SQL. Today I have had issues with change tracking and the lack of support to copy schemas for SQL compact.

The people I work for are not very patient people, neither am I if I am having to jump through hoops on simple things that people have complained about for years. I had envisaged enjoying the May day bank holiday weekend but I am wasting time fighting tools that should work. I worked really hard to get a stable app, and I need a pretty big schema change, that I had hoped VS 2010 would help in but there is absolutely no difference in visual studio for the problems I am trying to fix. I may as well be using visual studio 2008.

The syntax for the EF is horrible, horrible, horrible. They have a bunch of code that has been made obsolete between .NET 3.5 SP1 and now which clearly shows that they got a lot of things  wrong. The unintuativeness is a consequence of the fact that it is now a patch up job. They should have done what they did with WF and say, look, we've cocked up, back to the drawing board.

Just my 2 pence.

I tried using EF3.5sp1 for a project at work, which was a big mistake.  Next time I'll listen more to the ALT.NET people ... Too bad, because I like the idea of EF and the EDM, but the implementation is so clunky.

I have played with the EF4 Code Only feature (still a separate CTP download) a bit, and it does seem nice, but it also still feels incomplete.  

vesuvius said:

stun said:

*snip*

I know you guys are probably right, and I need to grow up and stop having tantrums, but I have a pretty complex bit of code using Linq to SQL, with primary keys that are auto-generated.

 

I choose Linq to SQL because of posts like this. Open up EF 4.0 and guess what, still no auto-generated keys.The key win with EF 4 is that it can reflect against SQL compact so my ORM is generated easily. This gets painful with Linq to SQL using sqlmetal.exe, manually editing the  ORM, but it allows for auto-generated keys. I cannot fathom for the life of me why the EF team have been inconsistent in this regard. This is how every other database and ORM on the planet works.

 

My key dislike is that the syntax is horrid, and it requires more steps not less to achieve the same thing in in EF 4.0 than Linq to SQL. Today I have had issues with change tracking and the lack of support to copy schemas for SQL compact.

 

The people I work for are not very patient people, neither am I if I am having to jump through hoops on simple things that people have complained about for years. I had envisaged enjoying the May day bank holiday weekend but I am wasting time fighting tools that should work. I worked really hard to get a stable app, and I need a pretty big schema change, that I had hoped VS 2010 would help in but there is absolutely no difference in visual studio for the problems I am trying to fix. I may as well be using visual studio 2008.

 

The syntax for the EF is horrible, horrible, horrible. They have a bunch of code that has been made obsolete between .NET 3.5 SP1 and now which clearly shows that they got a lot of things  wrong. The unintuativeness is a consequence of the fact that it is now a patch up job. They should have done what they did with WF and say, look, we've cocked up, back to the drawing board.

 

Just my 2 pence.

I would suggest depending on some kind of T4-based code generation and use the Repository design pattern data-access-tier.

I would recommend checking these out.

http://www.subsonicproject.com/

http://thedatafarm.com/blog/data-access/agile-entity-framework-4-repository-part-1-model-and-poco-classes/

(1) Then, you can probably generate most of the code without having to write them.

This might appease the impatient people in your team.

(2) Repository pattern will allow you to not use LINQ syntax queries in the UI and be flexible.

You can probably use some kind of Generic-based code for your "AddRange( )" method.

At this point in time, we should be minimizing as much manual coding as possible and work smarter. Not harder.

stun said:

vesuvius said:

*snip*

I would suggest depending on some kind of T4-based code generation and use the Repository design pattern data-access-tier.

 

I would recommend checking these out.

http://www.subsonicproject.com/

http://thedatafarm.com/blog/data-access/agile-entity-framework-4-repository-part-1-model-and-poco-classes/

 

 

(1) Then, you can probably generate most of the code without having to write them.

This might appease the impatient people in your team.

 

(2) Repository pattern will allow you to not use LINQ syntax queries in the UI and be flexible.

You can probably use some kind of Generic-based code for your "AddRange( )" method.

 

 

At this point in time, we should be minimizing as much manual coding as possible and work smarter. Not harder.

Thanks for the links, I will look at them.

On the server end I opted for Linq to SQL over EF in this excellent tutorial. I hope whoever determines MSDN content asks Tony back to do an updated version. Tony recently published the EF 4.0. version, I have watched his tutorial in which he exposes difficulties with EF 4.0 in some scenarios. Lets be honest, he is not about rubbishing EF 4.0, but is a pragmatic developer who knows the types of issues you are likely to face, thus I have DTO's in my service layer.

It's just that I feel I am going into a burger joint and paying more for less burger with EF 4.0. It was not meant to be that way. I remember watching the Subsonic videos a few years back (they were the first to expose Linq to SQL issues in n-tier, I think the video was linked to Rick Stahl and his expose), so this is an area I specialise in.

The implementation of EF with T4 templates is fantastic, and it generates a lot of bolierplate code for you.  I guess the thing is to wait a while, as extension methods allow for a reduction in the boilerplate coding one must do with EF 4.0 at present, but I must communicate my absolute dissapointment. Every single developer that uses SQL uses primary keys. How and why EF came to omit this leaves me thinking that the team is full of arrogant people that don't listen, that want to force me into using things the way that they want. This is a very big mistake for their client side implementation, and find little to no justification to using EF 4.0 over Linq to SQL, especially since I have far much less code.

EF team please answer me this, How can you say to people, please move onto EF 4.0 and don't use Linq to SQL (it replaces it), when it requires me to write far more code and it cannot cater for auto-generated primary keys which Linq to SQL can? Is this a step forward or not?

If LINQ to SQL isn't broken, why try and fix your app to use EF 4.0?

I know it's no longer a namespace that will be updated, but it should continue to work for your apps for a very long time.

We did a new app last year using EF, and there is a learning curve and nuances to overcome.

Looking back, I'm 50/50 on my decision to use EF. There are some advantages, but I'm not sure it's worth it at this time.

Red5 said:

If LINQ to SQL isn't broken, why try and fix your app to use EF 4.0?

I know it's no longer a namespace that will be updated, but it should continue to work for your apps for a very long time.

 

We did a new app last year using EF, and there is a learning curve and nuances to overcome.

Looking back, I'm 50/50 on my decision to use EF. There are some advantages, but I'm not sure it's worth it at this time.

Against SQL compact you have to use SQL metal.exe to generate the ORM, and it does not always work/update how you would expect. It also forgets settings sometimes, so you end up back to square one.

The ability to have the IDE reflect against the SQL compact database schema is a real time saver (EPIC WIN). It is also a pain to have the Linq to SQL ORM in its seperate DLL, getting the connection strings to work. It does work for simple use case scenarios, but I have a big schema and I am wasting time because the ORM loses it settings and relationships.

vesuvius said:

stun said:

*snip*

Thanks for the links, I will look at them.

 

On the server end I opted for Linq to SQL over EF in this excellent tutorial. I hope whoever determines MSDN content asks Tony back to do an updated version. Tony recently published the EF 4.0. version, I have watched his tutorial in which he exposes difficulties with EF 4.0 in some scenarios. Lets be honest, he is not about rubbishing EF 4.0, but is a pragmatic developer who knows the types of issues you are likely to face, thus I have DTO's in my service layer.

 

It's just that I feel I am going into a burger joint and paying more for less burger with EF 4.0. It was not meant to be that way. I remember watching the Subsonic videos a few years back (they were the first to expose Linq to SQL issues in n-tier, I think the video was linked to Rick Stahl and his expose), so this is an area I specialise in.

 

The implementation of EF with T4 templates is fantastic, and it generates a lot of bolierplate code for you.  I guess the thing is to wait a while, as extension methods allow for a reduction in the boilerplate coding one must do with EF 4.0 at present, but I must communicate my absolute dissapointment. Every single developer that uses SQL uses primary keys. How and why EF came to omit this leaves me thinking that the team is full of arrogant people that don't listen, that want to force me into using things the way that they want. This is a very big mistake for their client side implementation, and find little to no justification to using EF 4.0 over Linq to SQL, especially since I have far much less code.

 

EF team please answer me this, How can you say to people, please move onto EF 4.0 and don't use Linq to SQL (it replaces it), when it requires me to write far more code and it cannot cater for auto-generated primary keys which Linq to SQL can? Is this a step forward or not?

What do you mean by "auto-generated primary key"?

I am not sure I understand what you are trying to do here.

Aren't you just using the Database IDENTITY (or) GUID column for primary key?

If so, after you save to the database, EF will retrieve it for you right away.

Yeah I don't know how useful or flexible Subsonic is.

But I wrote my own T4 code-generation templates to generate code for

(1) Repository classes

(2) MVC Controllers

(3) MVC Views

(4) Metadata classes for my MVC Models

after that, a little bit of manual tweaking and I get *exactly* what I want with minimal coding time for repetitive tasks.

stun said:

vesuvius said:

*snip*

What do you mean by "auto-generated primary key"?

I am not sure I understand what you are trying to do here.

 

Aren't you just using the Database IDENTITY (or) GUID column for primary key?

If so, after you save to the database, EF will retrieve it for you right away.

 

 

 

Yeah I don't know how useful or flexible Subsonic is.

But I wrote my own T4 code-generation templates to generate code for

(1) Repository classes

(2) MVC Controllers

(3) MVC Views

(4) Metadata classes for my MVC Models

 

after that, a little bit of manual tweaking and I get *exactly* what I want with minimal coding time for repetitive tasks.

SQL CE only allows for 1 query at a time.

So when you insert a row, you would normally select back your generated key in the same command.

But because these are two queries, SQL CE does not permit it. That's why I think EF doesnt support it on CE, like vesuvius describes.

I did a project with both CE and Server, we quickly dropped the notion of an ORM and wrote our own datalayer.

Maddus Mattus said:

stun said:

*snip*

SQL CE only allows for 1 query at a time.

 

So when you insert a row, you would normally select back your generated key in the same command.

 

But because these are two queries, SQL CE does not permit it. That's why I think EF doesnt support it on CE, like vesuvius describes.

 

I did a project with both CE and Server, we quickly dropped the notion of an ORM and wrote our own datalayer.

I have finished the waste of two days work and gone back to Linq to SQL and everything works again. For the record this is a copy of my ORM table. The EF team choose not to support this. If it was an oversight in .NET 3.5, then it was missed again or ommitted purposefully. It precludes people from upgrading if they have to refactor all the data that their clients have. It also means that the error message they give saying SQL compact does not allow autogenerated inserts is wrong, and has misled an army of developers into thinking the database is at fault so Microsoft have two products reputation that is tarnished instead of one. SQL compact is an awesome little database folks.

vesuvius said:

Maddus Mattus said:

*snip*

I have finished the waste of two days work and gone back to Linq to SQL and everything works again. For the record this is a copy of my ORM table. The EF team choose not to support this. If it was an oversight in .NET 3.5, then it was missed again or ommitted purposefully. It precludes people from upgrading if they have to refactor all the data that their clients have. It also means that the error message they give saying SQL compact does not allow autogenerated inserts is wrong, and has misled an army of developers into thinking the database is at fault so Microsoft have two products reputation that is tarnished instead of one. SQL compact is an awesome little database folks.

 

 

 

Yes it is, but it has limitations. You should be aware of them.

One limitation is the one I mentioned. Products like EF tend to "forget" these limitations.

Is there an option that you say autogenerated is false and provide a select the row back after insert kinda thing?

Red5 said:

If LINQ to SQL isn't broken, why try and fix your app to use EF 4.0?

I know it's no longer a namespace that will be updated, but it should continue to work for your apps for a very long time.

 

We did a new app last year using EF, and there is a learning curve and nuances to overcome.

Looking back, I'm 50/50 on my decision to use EF. There are some advantages, but I'm not sure it's worth it at this time.

You mean LINQ to SQL is "dead"?

Maddus Mattus said:

vesuvius said:

*snip*

Yes it is, but it has limitations. You should be aware of them.

 

One limitation is the one I mentioned. Products like EF tend to "forget" these limitations.

 

Is there an option that you say autogenerated is false and provide a select the row back after insert kinda thing?

I am doing the select a row after on the server end behind the service layer so I don't require this on the SQL compact end, though I was using this extension method with EF 4.0 yesterday. In the unlikely event that Linq to SQL didn't give you the new row Id, then I'm sure a similar technique would work

Interesting post.

I've also been through the process of trying L2EF.  I'd hoped that EF 4 would be a big improvement.  (Haven't tried it yet.)

My guess is that L2S will endure indefinitely.  If it fits the job you're doing it often fits very well.

In response to turrican, L2S is not dead and was enhanced for .NET 4.  If you want more than L2S and are prepared to invest in CodeSmith they have taken it further with something called Plinqo.  L2S is in the distribution and serious applications depend on it, it would be very hard for MS to ditch it.  Like vesuvius there are others who have gone back to L2S after trying L2EF.

My personal hope is that L2EF becomes better,  maybe in the next version.  If the next is version 3, then maybe it will follow the old rule of thumb that, in version 3 it takes off.

(For those facing the choice themselves I've put up an experimental tool to help chose between L2S, L2EF and Plinqo referred to in this post http://decisionz.wordpress.com/2010/04/09/suggestions-for-linq-tool-to-use/ there is also a page with a few links to the debate over how best to use LINQ at http://www.decisionz.com/Services/Samples/LinqToolsFurtherReading.aspx.)

MikeJGale said:

Interesting post.

 

I've also been through the process of trying L2EF.  I'd hoped that EF 4 would be a big improvement.  (Haven't tried it yet.)

 

My guess is that L2S will endure indefinitely.  If it fits the job you're doing it often fits very well.

 

In response to turrican, L2S is not dead and was enhanced for .NET 4.  If you want more than L2S and are prepared to invest in CodeSmith they have taken it further with something called Plinqo.  L2S is in the distribution and serious applications depend on it, it would be very hard for MS to ditch it.  Like vesuvius there are others who have gone back to L2S after trying L2EF.

 

My personal hope is that L2EF becomes better,  maybe in the next version.  If the next is version 3, then maybe it will follow the old rule of thumb that, in version 3 it takes off.

 

(For those facing the choice themselves I've put up an experimental tool to help chose between L2S, L2EF and Plinqo referred to in this post http://decisionz.wordpress.com/2010/04/09/suggestions-for-linq-tool-to-use/ there is also a page with a few links to the debate over how best to use LINQ at http://www.decisionz.com/Services/Samples/LinqToolsFurtherReading.aspx.)

I am hoping there will be a 4.0SP1 = 4.1 a la 3.5SP1 = 3.6 that will address a lot of issues ...

contextfree said:

MikeJGale said:

*snip*

I am hoping there will be a 4.0SP1 = 4.1 a la 3.5SP1 = 3.6 that will address a lot of issues ...

If you are really into Linq to SQL, it lives on in the DbLinq project. It is an open source ORM that is API compatible with Linq to SQL.