June 2008 - Posts
Support for LINQ based O/R mappers Out of the box, ASP.NET Dynamic Data has support for both Linq To Sql and Entity Framework. In addition, it has a provider model which allows additional O/R mappers to be supported. For instance, we have a sample provider that supports ADO.NET Data Services (aka Astoria). There is also a provider for LLBLGen . Note that all those scenarios are some things in common: They are based on some form of data context : it's called various things in the different O/R mappers (DataContext, ObjectContext, DataServiceContext), but essentially it's a class that has a property for each Entity Set. They support LINQ : the Entity Set properties on the data context class implement IQueryable<T>...
Today, ASP.NET Dynamic Data moved from its current home on Code Gallery to its new home on CodePlex . Note that this is part of a general ASP.NET CodePlex project, so you'll see other features mentioned in there, like MVC and AJAX. This doesn't mean that those features tie with Dynamic Data any more than they did before; they're just sharing a home on the same CodePlex project. There are a couple different things related to Dynamic Data that are available there, and since there is room for confusion I'll try to help make sense of it all. The 'core' Dynamic Data The first piece is Dynamic Data itself. This will ship later this summer as part of Framework 3.5 SP1, but until that happens you need to install...
If you've used Dynamic Data or watched some demos, you may have been puzzled by the way metadata is associated with database fields. Instead of being placed directly on the partial Entity class (e.g. Product), it needs to go on a different class which gets associated with the real class via a MetadataTypeAttribute. Here is an example where we're adding a display name on the UnitsInStock column: [ MetadataType ( typeof ( Product_Metadata ))] public partial class Product { } public class Product_Metadata { [ DisplayName ( "The Units In Stock" )] public object UnitsInStock { get ; set ; } } Here are the key pieces at play: First you have the Product partial class, which is 'partial' with the Product class that was generated...
Suppose you're dealing with a table that has a foreign key relationship with another table. To take the canonical example, let's say we're looking at the Northwind Products table, which has a foreign key into the Categories table. What this means is that each Product is a member of a Category (and conversely, a Category can be seen as 'containing' a number of Products). What can make this situation a little confusing is that there are two related concepts that come into play, and can often be mixed up: The Foreign Key column : the Product class has a CategoryID property, which is an integer containing the ID of the Category that the Product is part of. In some cases, there can be multiple Foreign Key columns...
More Posts