I didn't write almost any article during past three months because I decided to pass several Microsoft certifications and I spend most of my free time be preparing for required exams. Two exams I definitely wanted to pass were:
Well, I passed those exams but I really didn't enjoy the experience. Especially the second exam is probably the worst one I have ever taken. In the rest of the article I will describe some of my opinion about these exams. Be aware that if you are looking for exam questions you will not find them here and I'm not going to share any detailed content of them.
The first version of Entity Framework introduced in .NET 3.5 SP1 (EFv1) contained only a single type of association between entities. All associations in EFv1 was based on the correct object oriented approach where a relation between entities is modelled as a reference between objects. The problem of this association type was the internal implementation in Entity framework which makes it sometimes (especially in detached scenarios) very hard to use. The next version of Entity Framework introduced in .NET 4.0 (EFv4) included a new type of association where conceptual model also includes foreign key properties to define connections between entities. To differ between these two types of associations ADO.NET team decided to call the old type Independent association and the new type Foreign key association.
The question is: Was introducing the new type of association a good design choice? I believe that Foreign key associations should not never be included and instead Independent association should be improved. The main reasons for introducing the new type of association are covered by the article on Entity Framework Design blog. The community was obviously divided between two groups where one group requested foreign keys whereas second group didn't want them. I'm the member of the second group because in my opinion ORM tool should not push relational concepts to the conceptual / object model. A foreign key is definitely a relational concept to model a relation and we rarely want it to pollute our object model.
Despite of that I agree with ADO.NET team that the final decision should be left to developers so if we want to include a foreign key property in our entity we should be able to do that. I don't agree with the way how it was achieved. The biggest problem is that a difference between Independent and Foreign key associations is not only in the way how they use foreign keys. These two association types are handled by EFv4 completely differently. The rest of the article will explain differences between these two association types and it will also mention how this affects Entity Framework 4.1 and its DbContext API.
ADO.NET team yesterday released final version of Entity Framework 4.1. It is again available as stand alone download or NuGet package. This version doesn't contain any API changes except changed default maximum length for string properties mapped with the code first approach. EF 4.1 RC used nvarchar(128) as default SQL type for all string properties. This caused some issues to many developers who didn't know how to change it. ADO.NET team also received some feedback and because of that the default value for a length of string properties was changed to Max for SQL Server and to 4000 for SQL Compact. That is in my opinion the worst choice because now 90% of databases created with the code-first approach will have all string columns defined as nvarchar(max).
One of very important features in ORM tools is an ability to get data auto-generated by a database during the entity persistence back to your application. The Entity framework supports this feature by setting StoreGeneratedPattern in the configuration of persisted property. The StoreGeneratedPattern setting is available in both SSDL (Store schema definition language) and CSDL (Conceptual schema definition language) parts of the EDMX file. CSDL configuration allows you defining the reloading behavior in the Model-first approach but SSDL part is responsible for generating correct SQL commands which will persist the entity and reload auto-generated properties. Unfortunately for a long time this was the source of all problems.
The feature was very hard to use because of the annoying bug in the Entity designer. When we set the property in the designer, the value was saved only in CSDL part but not in SSDL part of the EDMX file and the feature didn't work until we opened the EDMX file as XML and manually modified SSDL part. This solved the problem but only until we updated our model from the database. The update always deleted whole SSDL part including our manual change so we had to do it again. Any incremental development of our models become a big pain. The workaround was using mapped stored procedures for inserting and updating entities and mapping result sets (returning auto-generated data) from these stored procedures back to the entity. Finally this bug is solved in Visual Studio 2010 SP1 and we can use StoreGeneratedPattern without any problems because the value is correctly set in both CSDL and SSDL parts and it is not overwritten during updating from the database.
Update: If you still have problem with this issue install KB2561001. It should be the most recent fix for this bug in VS 2010.
Rest of the blog post describes usage of StoreGeneratedPattern.
ADO.NET team yesterday released Microsoft Entity Framework 4.1 Release Candidate which is now available for download as both stand alone installation and NuGet package. This release provides DbContext API with code first development approach for production usage. Final release will be available next month. This version contains only minor changes to previous CTP5 version so the most of examples provided for previous version (also check great posts on Morteza Manavi's blog) should still work. ADO.NET team also released two introduction articles about code first and about database and model first with DbContext. Finally, Julia Lerman also published several screencasts about Entity Framework 4 and 4.1 and their usage in different types of applications.
The missing support for unique keys is well known limitation of Entity framework 4. Few days ago, the Entity framework team has published the article which I take as announcement of unique keys support in the next version(s) of Entity Framework. After announced support for table-valued functions, it is the second nice feature targeting the next version of Entity framework announced this year. Just be aware that "the next version" does not mean Entity Framework 4.1 (the code-first).
Update: Unfortunately this feature will not be available in the next version. ADO.NET team didn't include the feature into .NET Framework 4.5 and we will have to wait at least till a next major release (.NET Framework service pack or next version).