You’ve heard good things about Visual Studio 2010 but you still need to answer the question “What’s in it for me?” You need to justify the cost the new software as well as the not insignificant cost of migration. The Entity Framework is a powerful tool for creating a conceptual model of your data store and abstract away the details of data access. Exposing these conceptual entities over the wire to client applications mean one of two things: ADO.NET Data Services (now called WCF Data Services) or hand rolling your own web services.
An ADO.NET Service is simple to implement but consuming them required a fairly deep understanding of how the entity tracking worked internally requiring you to manually manage changes to relationships between objects. The choice of REST (REpresentational State Transfer) for addressing and ATOM publishing as the wire format led to some serious performance limitations for all but the simplest of interactions. Other issues are revealed later in this post.
Rolling your own custom web services is “non-trivial” at best. Implementing an advanced pattern such as self-tracking entities is not for the faint of heart and probably not worth the effort. The reasons for this are described below.
I’ve put together this information to try and distill out the key benefits of the new features in EF 4 that make implementing web services much easier. Most of the available information gets rather technical so I’ve tried to point out the sections that are most relevant to the decision process. You can then have your technical staff delve deeper if they so desire. As you’ll see, the new tools and features available in VS2010 and Entity Framework 4 offer a much better alternative and plenty of flexibility.
First up is an article describing the various n-tier patterns that are in general use.
The article describes four different patterns: Change Set, DTOs (Data Transfer Objects), Simple Entities and Self-Tracking Entities. Self-Tracking Entities provide the best balance of architectural goodness and ease of implementation however, simple entities are the only realistically viable choice for use with the .NET 3.5 SP1 version of Entity Framework. This is described in the section entitled "Implementing N-Tier with the Entity Framework" but the key phrase is:
"The EF can be used to implement any of the four patterns described earlier, but various limitations in the first release of the Framework (shipped as part of Visual Studio 2008 SP1/.NET 3.5 SP1) make patterns other than the simple entities pattern very difficult to implement."
And from "Patterns Other Than Simple Entities in .NET 3.5 SP1":
"Unfortunately, self-tracking entities is the hardest pattern to implement in the SP1 release for two reasons. First, the EF in .NET 3.5 SP1 does not support POCO, so any self-tracking entities that you implement have a dependency on the 3.5 SP1 version of .NET, and the serialization format will not be as suitable for interoperability. You can address this by hand writing proxies for the client, but they will be tricky to implement correctly. Second, one of the nice features of self-tracking entities is that you can create a single graph of related entities with a mix of operations—some entities can be modified, others new, and still others marked for deletion—but implementing a method on the mid-tier to handle such a mixed graph is quite difficult. If you call the Attach method, it will walk the whole graph, attaching everything it can reach. Similarly, if you call the AddObject method, it will walk the whole graph and add everything it can reach. After either of those operations occurs, you will encounter cases in which you cannot easily transition some entities to their intended final state because the state manager allows only certain state transitions. You can move an entity from unchanged to modified, for instance, but you cannot move it from unchanged to added. To attach a mixed graph to the context, you need to shred your graph into individual entities, add or attach each one separately, and then reconnect the relationships. This code is very difficult. "
Skipping ahead to the last section entitled "API Improvements in .NET 4" reveals the following key statement (emphasis mine):
"In the upcoming release of the EF, which will ship with Visual Studio 2010 and .NET 4, we have made a number of improvements to ease the pain of implementing n-tier patterns—especially self-tracking entities. I'll touch on some of the most important features in the following paragraphs."
The next article focuses on "Building N-Tier Apps with EF4"
First up is a list of key new features that support N-Tier development:
- New framework methods that support disconnected operations, such as ChangeObjectState and ChangeRelationshipState, which change an entity or relationship to a new state (added or modified, for example); ApplyOriginalValues, which lets you set the original values for an entity; and the new ObjectMaterialized event, which fires whenever an entity is created by the framework.
- Support for Plain Old CLR Objects (POCO) and foreign key values on entities. These features let you create entity classes that can be shared between the mid-tier service implementation and other tiers, which may not have the same version of the Entity Framework (.NET 2.0 or Silverlight, for example). POCO objects with foreign keys also have a straightforward serialization format that simplifies interoperability with platforms like Java. The use of foreign keys also enables a much simpler concurrency model for relationships.
- T4 templates to customize code generation. These templates provide a way to generate classes implementing the Self-Tracking Entities or DTOs patterns.
And here's a big benefit in the first sentence after that list:
"The Entity Framework team has used these features to implement the Self-Tracking Entities pattern in a template, making that pattern a lot more accessible,...:
They've done pretty much all of the work for you in a code generation template!
Figure 1 in the article shows a graphic comparison of the various patterns for N-Tier architectures. Higher up on the y-axis means more architectural goodness and further right on the x-axis means easier to implement. You can see from the graph that self-tracking entities offer the best balance.
The rest of the article just goes into more details of the actual implementation.
As you can see from this information, moving to VS 2010/.NET 4 can provide enormous value to a project. I'd guess that roughly 90% of the code you'd have to write (hundreds and likely thousands of lines) gets automatically generated for you and the resulting objects will work with any version of .NET from 2.0 on.
Just because I can…