Microsoft’s data strategy is solidly focused on conceptual models. The Entity Framework is the tool for .NET developers to build applications that leverage these models. Yet version 1 is only the first step toward Microsoft’s larger vision for a very robust set of capabilities. In this book, you learned how to use the features in version 1 to build applications, and you gained a good understanding of the plumbing of the Entity Framework so that you can overcome some of the limitations of this version.
Microsoft has listened very closely to the developer community and has started to show publicly the features it is implementing in the next version, which will be part of the next Visual Studio release. Microsoft continues to work with the community and encourages our feedback in helping to shape this next version.
In the meantime, the company has been putting together samples of how to achieve some of the capabilities that are targeted for the next version, as well as code you can use to extend the Entity Framework’s current features.
In this chapter, we’ll take a brief look at a few lingering questions regarding the Entity Framework, the version 1 toolkits that Microsoft has been sharing, and some of what’s coming in the next version, which will be part of Visual Studio 2010 and .NET 4.0.
We did not discuss reporting in this book because there is not
much to share. In Windows Forms, the embedded Microsoft Report Creator
and the Crystal Reports Report Builder can build reports from DataSource objects, including those that you
create from entities. However, the bridge between the entities and the
reporting tools has a hole that prevents you from building reports from
entity graphs, thereby removing most of the usefulness of employing the
report builders.
As of this writing, none of the third-party vendors had created a
reporting tool that will work with the Entity Data Model (EDM) or
EntityObjects and graphs. However,
for the next version of SQL Server, Reporting Services will be embracing
the EDM concept and you will be able to build reports against the
conceptual model.
Until then, you’ll have to create reports directly from the database as you would do for most other Object Relational Mapping tools. And, of course, keep an eye on the third-party vendors that could very well release something in the meantime.
LINQ to SQL was released with Visual Studio 2008, allowing more developers to adopt and implement it into production systems quickly. The Entity Framework was not released until 10 months later as part of Visual Studio 2008 Service Pack 1.
LINQ to SQL is a much lighter-weight API that is perfect for
quickly implementing a data layer. It does not approach the level of
granularity that the Entity Framework allows you in order to control
how your objects are handled from query to materialization and back to
the database. LINQ to SQL also does not provide a way to stream data,
as you can with EntityClient.
With the Entity Framework, you have the option of querying with LINQ to Entities or Entity SQL. Entity SQL is a great choice when you need to build queries dynamically. Although LINQ to SQL doesn’t have another mechanism for building queries, there is a helper library called the LINQ Dynamic Query Library that can be used with any LINQ provider, including LINQ to SQL and even LINQ to Entities. It’s not as flexible as Entity SQL, but it certainly provides a lot of capability when using LINQ methods. You can read all about this library on Scott Guthrie’s blog at http://weblogs.asp.net/scottgu/archive/2008/01/07/dynamic-linq-part-1-using-the-linq-dynamic-query-library.aspx. Otherwise, you are bound to the strongly typed query language and cannot build dynamic queries.
LINQ to SQL works only with SQL Server, whereas the Entity Framework works against any database for which there is a provider. However, many LINQ providers are available and some of those work against databases.
LINQ to SQL’s model is a set of classes that tie directly to the database tables and columns with class attributes, which is very different from the conceptual model that the Entity Framework uses along with the schema files that map back to the database.
LINQ to SQL has the same issues regarding working with data across tiers as the Entity Framework does, in that change-tracking data disappears. Developers trying to solve this problem for LINQ to SQL have come up with solutions similar to those you have seen in this book for the Entity Framework.
Both the Entity Framework and LINQ to SQL are part of ADO.NET and are controlled by the same development team at Microsoft.
As I mentioned at the beginning of this book, Microsoft has recently made it clear that because it will be investing in the Entity Framework as part of its data platform strategy, LINQ to SQL will be maintained and tweaked but will not benefit from the same level of evolution and innovation as the Entity Framework. You can read more on the ADO.NET team blog, at http://blogs.msdn.com/adonet/, for posts made from late October 2008 onward.
Beginning in mid-October 2008, the ADO.NET team began providing guidance on migrating LINQ to SQL projects to the Entity Framework in various posts on their blog (http://blogs.msdn.com/adonet/). Microsoft has said that it will provide this guidance, but to date it is not yet available. Formal guidance as well as tools will be provided to help you migrate if you wish to.
Although the Entity Framework team is doggedly working on the next version, in the meantime they have shared a lot of additional tools and sample code on the MSDN Code Gallery website. The URL for that jumping-off page for all Entity Framework team projects is http://code.msdn.microsoft.com/adonetefx/.
As you have seen throughout this book, extra coding is required in a lot of places to achieve functionality that would be nice to have built-in to the framework. A number of Entity Framework team members have worked out some of these problems for us, and have posted their solutions on Code Gallery. Some of these examples are ideas that the team is exploring for planned enhancements for version 2. In the next several subsections, I’ll highlight some of the tools that are available as of this writing.
The EFExtensions provide lots of tricks, including the ability
to call stored procedures that return multiple resultsets (as long
as those results match up with existing entities). They also provide
the ability to create types from DataReader, and they include a sample
application that demonstrates these and other features built into
the extensions.
POCO (Plain Old CLR Objects) is coming in the Entity Framework
version 2 to allow for programming and unit testing in a way that
doesn’t require tight coupling to the ObjectContext. The POCO Adapter allows you
to achieve this with version 1.
If you do not like the fact that the Entity Framework forces
you to call Load to explicitly
load related data for an entity, you might be interested in
implementing lazy loading. Entity Framework Lazy Loading will
provide implicit lazy loading so that if you already have a customer
and you want the customer’s orders, referencing Customer.Orders will cause the Entity
Framework to load the orders behind the scenes.
Entity Framework Lazy Loading also provides a number of additional utilities that can help you get over a hump or can show you the code for solving particular types of problems.
The same Code Gallery project also provides a number of samples.
Entity Framework Query Samples is a Visual Studio project that contains a slew of sample queries for LINQ to Entities and Entity SQL.
The Entity Framework version 1 is a very robust tool, but as you have seen throughout this book, many features require that you dig deeper than you may have wanted to in order to accomplish certain tasks. The Designer has a lot of features, but it does not support many of the mappings that you can achieve in the EDM, which requires you to handcode directly in the XML and, in certain cases (such as when using complex types), completely abandon the Designer.
Version 1 was “wrapped up” months before it shipped, and the Entity Framework team was already hard at work improving the Entity Framework for its next release.
At Microsoft PDC2008, Program Manager Tim Mallalieu presented “Entity Framework,” where he demonstrated a number of the new features that are being implemented in the next version. You can view all of the videos from the conference at http://www.microsoftpdc.com/.
Among these features are the following:
- A more robust Designer
Two features that Mallalieu demonstrated are Designer support for complex types and “model first” design capabilities. You can begin by designing a model and then create a database from it. Combined with the Update Model from the Database tool, you can then do iterative development of both the model and the database.
- Support for POCO to enable Agile development and unit testing
that is not dependent on
ObjectContext What’s most interesting about this demo is that it solidifies the idea that the EDM is a concept. With the POCO classes, there is no need for the XML files. The model will be dynamically created in memory based on the classes as they are instantiated.
- Support for model-driven development
If you would rather design your model and create your database from there, you’ll be able to do this in the next version. The team established an Entity Framework Advisory Council, which includes Domain Development gurus such as Eric Evans and Jimmy Nillsson to help them with this area of expansion.
- Support for computed properties in the model so that you don’t have to rely on partial classes and you can include those properties in queries
This new feature is similar to
DefiningQueries, which we discussed in Chapter 13. It is called aDefiningExpression, and is defined in the model and can be linked to a class property using attributes.
Other important topics that were discussed but not demonstrated include better support for stored procedures and better support for change tracking across tiers.
Much more is happening with the next version of the Entity Framework, and these changes will become more visible as the team solidifies some of the code and includes it in upcoming betas of Visual Studio 2010. By the time this book is in print a lot more information about the next version of the Entity Framework will likely be publicly available.
The Entity Framework team wants to get more input regarding the design of the .NET 4.0 version of the Entity Framework. Toward that end, they have created the Entity Framework Design blog, where they blog the ideas they are working on and request feedback from the community. You can find this blog at http://blogs.msdn.com/efdesign/.
If you are looking for additional information and discussion on the Entity Framework, the Resources page of the book’s website has many links to resources such as the MSDN Forum for the Entity Framework, screencasts and blogs about the Entity Framework, and a growing list of ADO.NET providers that support the Entity Framework.