My fear, like any sensible person, is in not using a beta, and having to waste time in tracing hard 2 find bugs, or things start not working, so it’s “better the devil you know” in .NET 3.5.

Thanks you again for the advice, it is very much appreciated.

Regards,

Ira

I’m afraid you’re mistaken on the EF4 timeline. RTM for EF4 is synchronized with .NET 4.0 and VS 2010. Although the release date had been Mar 22, 2010, it has been delayed “a few weeks” according to the announcement. Nevertheless, they’re releasing a RC that should be almost identical to RTM and includes a go-live license. The only major feature that won’t make it into RTM is Code-Only, which will come later.

In terms of change-tracking, STE’s have change-tracking implemented as part of the code-gen produced by the T4 template, which is fully customizable. Using that will be the most straightforward, although you could opt for DTO’s, such as what I demoed in my article. See Danny Simmon’s recent MSDN magazine article on n-tier EF4 for more info on the DTO approach vs STE’s.

In terms of collection serialization, using STE’s would alleviate you from that concern as well, and you wouldn’t have to hack the XML, because the client is referencing the entities assembly instead of having the VS service-reference generate them (which is what I did in the article).

I recommend again that you check out the STE walk-through I did, as well as that posted by the EF team on the ADO.NET team blog. STE’s represent I think a positive evolution of ideas I presented in my article, so they’re worth checking out.

Cheers,
Tony

@Does this answer your question?

I would have to say, yes and no. Though I know Visual Studio 2010 is beta 2, with a release candidate coming out next month, the fact that EF 4.0 is still CTP 2 says to me that it will be 6 months or maybe VS 2010 SP1 before it is released.

I like the way the change tracker works in the MSDN sample, and it should be relatively straightforward to upgrade to EF 4.0 once that is beta or RC.

I have also had issues with WCF especially hacking the XML to allow for the change tracking if my project has modules in different .dll’s. I have moved everything into my main application for the moment, and hope the WCF team have allowed for flexible UDT collections.

Were it to be that EF is nearly done and released soon, then I’d probably move to Dev 10.

Regards,
Ira

The answer to your question really depends on the type of application you’re developing and how “strategic” you want to be. I’m actually quite a big fan of LINQ to SQL, so if it’s not a critical line-of-business app and you’re sure of always having SQL Server on the back end, then L2S is a good choice.

L2S, however, although not completely dead, it’s definitely on the way out. If your application is going to be around for a while, the more strategic approach is to bite the bullet and go for Entity Framework 4.0. This version is definitely ready for prime-time and CTP 2 has everything there you need (except for an updated POCO template, but you’re OK if using STE’s). Of course, as you know from my article, you should architect your app with a Data Access Layer and use Self-Tracking Entities for your POCO’s so that the persistence technology (L2S, EF or whatever) is decoupled from the rest of the app.

Does this answer your question? I have a walk-though for STEs, which you can find here: http://blog.tonysneed.com/2009/11/12/ef-4-0-n-tier-support-take-2.

Cheers,
Tony

I am corrently working through your year old article on MSDN and have choosed Linq2SQL. My application goes live in 2-3 months so would you recomment I take the plunge and develop live with the EF CTP?

Tony

Without doing this your solution won’t even compile.

My problem is run-time, but I found the reason, please see:

http://blogs.msdn.com/adonet/archive/2009/11/04/ado-net-entity-framework-community-technology-preview-released.aspx?CommentPosted=true#commentmessage

kr,
Michel.

You need to change the template to point to where the edmx file is located. For example: To reference it from another project, open Northwind.Types.tt and modify inputFile initialization as follows: string inputFile = @”..\NorthwindData\Northwind.edmx”;

Please let me know if this answers your question. Cheers,

Tony