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
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
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.