Using the Entity Framework is Microsoft’s latest Data Access technique. Hopefully, they will settle on this one for a few versions. The version of the Entity Framework in .Net 4 is the first real version, if you ask me. The problems with predecessors are sick. Good work guys.
The Entity Framework lets you use LINQ syntax to access your data with a robust mapping engine to use across various data sources. LINQ allows you to create controlled, in-code queries against your data sources without requiring stored procedures or lots of code.
The Entity Framework allows you to, optionally, use code generated Self-Tracking Entities, for example, that have the ability to track their changes. Code generated entities allow you to introduce your own enhancements to the entities without worrying about screwing up the Entity Framework.
The Entity Framework allows you to break out the Model into a separate project, and your entities into a separate, reusable project.
Introducing ADO Data Services. It isn’t new, but now it’s native. It’s a WCF Service that enables LINQ queries on the client. Data Services isn’t super-documented right now. So custom query strings, and reusing entity types on the client isn’t straight forward.
There’s a bug in how types are reused on the client. And the techniques to use custom query strings and security in Data Services isn’t clear.
Data Services really lets you use a service oriented architecture with EF. But, to be fair, it even lets you use it with LINQ 2 SQL (LinqToSQL). LinqToSQL is not deprecated, but you should consider it deprecated in your own head. Just start using Entity Framework and thank me later.
Okay, I hope these short screen casts help you. Let me know!
1. How do you create an EF model in a stand-alone, reusable assembly – and then consume it in a simple WCF Data Service?
2. How do you extract the entities from the model, and move them to a stand-alone, reusable assembly – and then consume them?
3. How do you use the Data Service and enable the service reference to properly reuse the entity types on the client?
4. How do you introduce a custom SQL connection string when using a data service? Is it really this difficult?
In case you wanted to know, I use VS 2010, and SQL 2008. I’m inside Windows 7 Ultimate, but I don’t think those details matter so much. I hope these casts help you. Honestly, I created them to help me remember the little tricks necessary to get it all to work – in six months ;)
Next to figure out: How to save data back to the database without an error?!
Then to figure out: Simple Security with Data Services
[Update 6/2/10] As the architect of our current project, I had to make the call to drop using Data Services. EF is just fine. The delays we hit trying to get simple tasks working killed us. Fortunately, we dedicated a sprint to validate Data Services. I believe, until the WCF team fixes the known Service Reference bug, Data Services is useless.
- Why can’t Data Services support the SQL [time] data type?
- Why can’t Data Services have used Include(), like EF, instead of Expand()?
- Why can’t Data Services’ Expand() use “Child.GrandChild” syntax like EF Include() instead of a just-to-be-different “Child/GrandChild” syntax?
- Why can’t Data Services attach and update with EF syntax?
- Why can’t I query against an Expanded child collection/navigation property?
- Why can’t Data Services just work? There was so much promise!
Some of those gripes, to be fair, might be a result that ODATA was the result of a standards committee and, maybe, EF needs a little hit on the head instead. Uniformity, guys!
Also, I saw where WCF Data Services (actually ODATA) was written up in MSDN magazine this month (June 2010). The article never makes this point, but it’s clear to me based on my experience and the documentation and samples I see: ODATA is good as a simple “read” operations, but complex reading or simple writing isn’t where is should be. Not at all.
So, it’s “wait for Service Pack next” for us…