Angle Bracket Percent : Dynamic Data

Peter Blum’s new blog and his cool new data source controls

davidebb — Fri, 13 Nov 2009 01:19:54 GMT

Peter Blum has been well known is the ASP.NET world for many years for writing a whole suite of powerful controls, which you can read all about on his site. One thing that was missing on Peter’s resume is that he never had a blog. Well he started one earlier this month, and is making up for the lost time in a big way, with already 11 posts! And we’re not talking about small posts that just point to other people’s stuff (unlike this post I suppose!), but real with useful meaty content. Make sure you check out his blog at http://weblogs.asp.net/peterblum/. I hope he keeps the good stuff coming!

In particular, Peter has been working hard on some interesting data source controls that work with Visual Studio 2010. He’s calling them the ‘Versatile DataSources’, and is making it all available for free on CodePlex.

The following posts on his blog describe the data source controls:

First, an Intro Post
Then a follow up post with more details and many code samples

The simplest way to try out his controls is to download them from CodePlex. The package contains a rich set of samples that you can directly run and play with. You’ll need VS2010 Beta 2 to run this, so if you don’t already have it, get it from here.

I haven’t fully tried everything yet, but the one I played with the most is his POCODataSource, which is quite interesting. The core idea is very simple: you give it a type and it makes it easy to put up a WebForms UI to fill up an instance of that type. The UI supports full validation using standard model annotations supported by Dynamic Data.

The beauty is that it’s really quite easy to use. The data source declaration looks something like this (borrowed from Peter’s samples):

   <poco:POCODataSource ID="POCODataSource1" runat="server" POCOTypeName="CEOEmailGenerator" />

For the actual UI, you can use any standard ASP.NET data control like DetailsView, FormView or some similar 3rd party control. Then when an Update operation happens, you simply access the built instance from the data source using POCODataSource1.POCOInstance. At that point, you can do whatever you want with it. In Peter’s sample, he ends up calling an action method directly on the object, e.g.

protected void FormView1_ItemUpdated(object sender, FormViewUpdatedEventArgs e) {
   if (Page.IsValid) {
      ((CEOEmailGenerator)POCODataSource1.POCOInstance).Send();
   }
}

But I don’t see anything that ties you to this pattern, and you could instead just call some helper method and pass the object if your object doesn’t have an action method itself.

Anyway, check it out in much more details on Peter’s blog!

Using an Associated Metadata Class outside Dynamic Data

davidebb — Sat, 25 Jul 2009 04:31:00 GMT

A while back, I blogged about how ASP.NET Dynamic Data apps can uses an Associated Metadata class (aka a ‘buddy’ class) to add metadata attributed to properties defined in a generated class. It’s a mostly ugly thing that was made necessary by limitations of the C# and VB.NET languages: they don’t let you add attributes to properties defined in another partial class.

What I didn’t mention there is that this ‘buddy’ class mechanism is actually not specific to Dynamic Data apps, and can in fact be used anywhere. Since I’ve recently heard of several cases of users trying to do something similar, I’ll describe how it’s done. If you’re familiar with TypeDescriptionProviders (which have been around since ancient times), this will look very trivial.

I will illustrate this in a very simple console app to keep all other distractions out of the picture (the full sample is attached to the post). So the general scenario is that we have a generated class somewhere, e.g.

// Assume that this is generated code that should never be hand modified.
// Hence metadata attributes can't be added directly here

public partial class Product {
    public string Name { get; set; }

    public int UnitsInStock { get; set; }
}

Instead, the buddy provider let’s you write:

[MetadataType(typeof(Product_Metadata))]
public partial class Product {
}

class Product_Metadata {
    [DisplayName("The Units In Stock")]
    public object UnitsInStock { get; set; }
}

This works in Dynamic Data, but if we’re in some other context, no one will find our Product_Metadata ‘buddy’. In our to hook it up ourselves, we just need to make one call!

TypeDescriptor.AddProvider(
    new AssociatedMetadataTypeTypeDescriptionProvider(typeof(Product)),
    typeof(Product));

Pretty trivial stuff: we instantiate a TypeDescriptionProvider (with a somewhat scary name, I’ll give you that) and we register it by calling TypeDescriptor.AddProvider.

Once we do that, the attributes on the ‘buddy’ class magically show up as if they were defined on the real class:

// Get the property descriptor for UnitsInStock
PropertyDescriptor propDesc = TypeDescriptor.GetProperties(
    typeof(Product)).Find("UnitsInStock", true);

// Get the display name attribute, which is not actually on the property,
// but on its counterpart in the 'buddy' class
var displayName = propDesc.Attributes.OfType<DisplayNameAttribute>().First();

And that’s pretty much it. One important thing to notice here is that we are not using the standard reflection API (which would look like typeof(Product).GetCustomAttributes()), but we are instead using the TypeDescriptor API from the System.ComponentModel model namespace.

So to summarize, you can easily use this ‘buddy’ class mechanism anytime you deal with generated code that you need to annotate with attributes. And even though it’s not pretty to have to use that extra class, it’s comes very handy when there is no alternative. Maybe the day will come when C# will support doing this more cleanly, but in the meantime that’ll have to do!

Using a DomainService in ASP.NET and Dynamic Data

davidebb — Wed, 25 Mar 2009 04:52:02 GMT

One of the big things that I discussed in my MIX talk is the new DomainDataSource control. It is currently available in Preview form as part of ASP.NET Dynamic Data 4.0 Preview 3. This can be confusing, because even though Dynamic Data makes use of DomainDataSource, DomainDataSource is absolutely not tied to Dynamic Data, and is fully usable in ‘regular’ aspx pages.

In addition to this preview, you’ll want to also install Microsoft .NET RIA Services in order to get some useful tooling. This too can be confusing, because it makes it sound like it’s tied to RIA and Silverlight in some way, when in fact it is not.

The deal is that there is this new thing called a DomainService, which is essentially a Business Layer class that exposes CRUD methods. Once you have a DomainService, you can use it in various scenarios, including ASP.NET apps and Silverlight apps. Here, we will focus on its use from ASP.NET. For more information about the Silverlight side of things, check out Nikhil’s post (and his MIX talk).

Important: after getting the ASP.NET DD preview and the RIA Services mentioned above, you’ll need to do a little extra step to avoid a tricky setup issue. Find System.Web.DynamicData.dll under DefaultDomainServiceProject\bin in the ASP.NET Preview zip file, and copy it over the one in \Program Files\Microsoft SDKs\RIA Services\v1.0\Libraries\Server (which is where the RIA install puts them).

Now you’re actually ready to start playing with DomainService.

First, you’ll want to make a copy of the whole DefaultDomainServiceProject folder so you can work with it without touching the ‘original’. Then, just open DefaultDomainServiceProject.sln in VS. Normally, this would be a Project Template, but right now we don’t have one.

Creating a DomainService

DefaultDomainServiceProject comes with a default DomainService, but to make things more interesting you should just delete it and recreate one from scratch. Just delete DomainServices\NorthwindEntitiesDomainService.cs.

Now right click on DomainServices, choose Add New Item, and pick Domain Service Class. Name it for instance Catalog.

You’ll see a New Domain Service dialog. In here, do the following:

Uncheck Enable Client Access. That’s only useful for the Silverlight scenario.
Check Categories and Products. For Products, also click the right check box to enable editing.
Check ‘Generate associated classes’ at the bottom. This will be useful for Dynamic Data.

You should end up with a class that looks like this:

public class Catalog : LinqToEntitiesDomainService<NorthwindEntities> {

    public IQueryable<Categories> GetCategories() {
        return this.Context.Categories;
    }

    public IQueryable<Products> GetProducts() {
        return this.Context.Products;
    }

    public void InsertProducts(Products products) {
        this.Context.AddToProducts(products);
    }

    public void UpdateProducts(Products currentProducts, Products originalProducts) {
        this.Context.AttachAsModified(currentProducts, originalProducts);
    }

    public void DeleteProducts(Products products) {
        if ((products.EntityState == EntityState.Detached)) {
            this.Context.Attach(products);
        }
        this.Context.DeleteObject(products);
    }

Basically, it’s just a class for a few CRUD methods that you want to expose. In this case, it’s working over an Entity Framework model (hence the base class), but it would look similar with Linq to SQL or other ORM technologies.

The important part is that all data access goes through those methods, so you have full control over it. This is quite different from using LinqDataSource/EntityDataSource, where they talk directly to the DAL without going through your code. You have to write a little code, but the extra control you get makes it well worth it!

Registering your DomainService with Dynamic Data

Before we get into writing ‘standard’ ASP.NET pages by hand (in future posts), we’ll use Dynamic Data to get started quickly. To do this, simply add this line to global.asax (replacing the similar line that’s already there):

DefaultModel.RegisterContext(
    new DomainModelProvider(typeof(Catalog)),
    new ContextConfiguration() { ScaffoldAllTables = true });

Running it

Now you can just Ctrl-F5 and you should get a working Dynamic Data app. Note how it only lets you do things for which you have CRUD methods. e.g. you can edit Products but not Categories.

To make things more interesting, try various things:

Debug the app and set break points in your CRUD methods to see them getting called.
Change GetProduct() to only return a subset of the products, and watch it affect the UI
Change UpdateProduct() to modify the product before saving it,
Add some Dynamic Data style metadata in DomainServices\Catalog.metadata.cs. e.g. add a [Range(0, 100)] attribute to some integer field, and try an edit that violates the range

Conclusion

This was really just a quick intro to using DomainService in ASP.NET and Dynamic Data. I’ll try to follow up with some posts that go into more details on how to use DomainDataSource directly in a page without involving any Dynamic Data. To reiterate, though Dynamic Data works great with DomainDataSource, DomainDataSource completely stands on its own without Dynamic Data (as was shown in my MIX talk).

My MIX 2009 ASP.NET Data talk is available online

davidebb — Tue, 24 Mar 2009 09:41:59 GMT

Last Friday, I gave a talk at MIX on various things that we’re working on in ASP.NET data land. This includes both some Dynamic Data features and some features usable outside Dynamic Data.

The great thing about MIX is that they make all talks freely available online shortly after, and you can watch mine here. Enjoy!

I’ll try to blog in more detail about some of the features discussed in the talk in the next few days.

A helper to easily set up change notifications in Entity Framework

davidebb — Sat, 10 Jan 2009 05:39:00 GMT

When you use Entity Framework, you can perform Insert/Update/Delete operations on your entities, and you eventually call ObjectContext.SaveChanges() to actually make it all happen. The call to SaveChanges() is either explicit, or can happen implicitly when you use the EntityDataSource (e.g. within a Dynamic Data application).

Before SaveChanges() actually performs the operations, it gives you a chance to look at the entities, letting you modify them, and possibly cancel certain operations. Unfortunately, doing this requires using some pretty ugly code, because the API is a little too low level. Instead of nicely handing you the changes one by one, it just gives you the raw change list and lets you deal with it.

For instance, suppose you want to do something special when a Product is being updated. You have to:

Register for the ObjectContext.SavingChanges event
In your handler, call ObjectStateManager.GetObjectStateEntries(EntityState.Modified)
Go through the whole list looking for those where stateEntry.Entity is a Product
Finally they can do what they want with the Product

While certainly possible, it’s a lot more pain than it should be! To make this easier, we’ll write a little helper which lets you trivially listen to the changes you care about.

Before we get to the implementation of the helper, let’s look at the end result with the helper. It lets you write something like this:

public partial class NorthwindEntities {
    partial void OnContextCreated() {
        // This line hooks up the change notifications
        this.SetupChangeNotifications();
    }
}

public partial class Products : INotifyUpdating {
    public bool Updating() {
        // Make a small change to test that you can affect the entity
        ProductName += "!";
        return true;
    }
}

public partial class Categories : INotifyDeleting {
    public bool Deleting() {
        // Prevent the deletion
        return false;
    }
}

Notice how you just need to implement a simple interface on the partial class on the relevant entity type in order to get notified. You don’t need to know anything about the change list, or other such low level things.

Now let’s take a look at how the help works. First, we define the Insert/Update/Delete interfaces:

public interface INotifyInserting {
    /// <summary>
    /// Return false to cancel the Insert operation
    /// </summary>
    bool Inserting();
}

public interface INotifyUpdating {
    /// <summary>
    /// Return false to cancel the Update operation
    /// </summary>
    bool Updating();
}

public interface INotifyDeleting {
    /// <summary>
    /// Return false to cancel the Delete operation
    /// </summary>
    bool Deleting();
}

Pretty simple stuff. And now, the core logic that makes it all happen:

public static class EntityFrameworkHelpers {
    public static void SetupChangeNotifications(this ObjectContext context) {
        new ObjectContextHelper(context);
    }

    private class ObjectContextHelper {
        ObjectContext _context;

        public ObjectContextHelper(ObjectContext context) {
            // Keep track of the context
            _context = context;

            // Register for the SavingChanges event
            _context.SavingChanges += new EventHandler(Context_SavingChanges);
        }

        void Context_SavingChanges(object sender, EventArgs e) {
            // Go through all the Insert/Update/Delete changes and notify the user code if needed
            ProcessObjectStateEntries(EntityState.Added);
            ProcessObjectStateEntries(EntityState.Modified);
            ProcessObjectStateEntries(EntityState.Deleted);
        }

        private void ProcessObjectStateEntries(EntityState entityState) {
            // Go through all the entries
            foreach (ObjectStateEntry entry in _context.ObjectStateManager.GetObjectStateEntries(entityState)) {

                if (entry.Entity == null)
                    continue;

                // If the entity implements the interface (Insert, Update or Delete), call the
                // method.  If it returns false, cancel the operation
                bool proceedWithChange = true;
                switch (entityState) {
                    case EntityState.Added:
                        var notifyInserting = entry.Entity as INotifyInserting;
                        if (notifyInserting != null)
                            proceedWithChange = notifyInserting.Inserting();
                        break;
                    case EntityState.Modified:
                        var notifyUpdating = entry.Entity as INotifyUpdating;
                        if (notifyUpdating != null)
                            proceedWithChange = notifyUpdating.Updating();
                        break;
                    case EntityState.Deleted:
                        var notifyDeleting = entry.Entity as INotifyDeleting;
                        if (notifyDeleting != null)
                            proceedWithChange = notifyDeleting.Deleting();
                        break;
                }

                // If the method returned false, cancel the change
                if (!proceedWithChange)
                    entry.AcceptChanges();
            }
        }
    }
}

I’ll let the comments speak for themselves here. But in any case, you don’t really need to look at the details of this code if you just want to use the helpers.

I attached a complete Dynamic Data solution that includes and uses the helpers, so just download it and start from there!

Two worlds of Dynamic Data customization: generic vs schema specific

davidebb — Tue, 23 Dec 2008 02:44:00 GMT

There are many ways to customize a ASP.NET Dynamic Data site, which can sometimes be a bit overwhelming to newcomers. Before deciding what customization makes sense for you, it is important to understand the two major buckets that they fall into:

Generic customization: things that apply generically to any table/column.
Schema specific customization: things that apply to specific tables and/or columns.

They can both very useful depending on your scenario, but it is important to understand how they are different in order to make the right choices. The rule of thumb is that you want to stay in the world of generic customization whenever possible, and only use the schema specific customization when you have to. Doing this will increase reusability and decrease redundancy.

We’ll now look at each in more details.

Generic customization

Generic customization includes everything that you can do without any knowledge of the database schema that it will be applied to. That is, it’s the type of things that you can write once and potentially use without changes for any number of projects. It lets you achieve a consistent and uniform behavior across an arbitrarily large schema, without needing to do any additional work every time you add or modify a table.

Here are some key types of generic customization:

Page Template customization

Under the ~/DynamicData/PageTemplates folder, you’ll find some default Page Templates like List.aspx and Edit.aspx. If you look at them, you won’t find any references to a specific table/column. Instead, they define the general layout and look-and-feel of your pages in an agnostic way.

e.g. if you look at List.aspx, you’ll see a GridView and a LinqDataSource (or EntityDataSource with Entity Framework), but the data source doesn’t have any ContextTypeName/TableName attributes, and the GridView doesn’t define a column set. Instead, all of that gets set dynamically at runtime based on what table is being accessed.

You can easily make changes to these Page Templates, such as modifying the layout, adding some new controls or adding logic to the code behind. It’s a ‘normal’ aspx page, so you can treat is as such, but you should never add anything to it that is specific to your schema. When you feel the need to do this, you need to instead create a Custom Page (see below).

Field Template customization

Under the ~/DynamicData/FieldTemplates folder, you’ll find a whole bunch of field templates, which are used to handle one piece of data of a given type. e.g. DateTime_Edit.ascx handles DateTime columns when they’re being edited.

As is the case for Page Templates, Field Templates should always be schema agnostic. That is, you don’t write a field template that’s only meant to handle a specific column of a specific table. Instead, you write a field template that can handle all columns of a certain type.

For example, in this post I describe a field template that can handle Many To Many relationships. It will work for any such relationship in any schema (though it is Entity Framework specific).

Field Generator customization

Under Page Template above, I mentioned that the GridView didn’t specify a column set. Instead, the way it works is that there is something called a Field Generator which comes up with the set of columns to use for the current table.

The idea is that the Field Generator can look at the full column set for a table, and use an arbitrary set of rules to decide which one to include, and in what order to include them. e.g. it can choose to look at custom model attributes to decide what to show.

Steve Naughton has a great post on writing a custom field generator, so I encourage you to read that for more info on that topic.

Schema specific customization

Any time you make a customization that is specific to a certain table or column, you are doing schema specific customization. Here are the main type of things you can do:

Custom Pages

When you want to have a very specific look for a certain page (e.g. for the Edit page for your Product table), a generic Page Template will no longer do the job. At that point, you want to create a Custom Page. Those live under ~/DynamicData/CustomPages/[TableName]. e.g. to have a custom page to edit products, you would create a ~/DynamicData/CustomPages/Products/Edit.aspx.

You can start out with the custom page being an identical copy of the page template, but then you can start making all kind of schema specific changes. For instance, you could define a custom <Fields> collection in the DetailsView, at which point you no longer rely on the Field Generator (discussed below). Taking this one step further, you can switch from a DetailsView into a FormView (or ListView), giving you full control over the layout of the fields.

Model annotations

Another very important type of schema specific customization is model annotation. This is what most introductory Dynamic Data demos show, where you add CLR attributes to the partial class of your entity classes.

For instance, you can add a [Range(0, 100)] attribute to an integer field to specify that it should only take values between 0 and 100. Dynamic Data comes with a number of built-in annotation attributes, and you can easily build your own to add news ways to annotate your model.

The general idea here is that it is cleaner to add knowledge at the model level than to do it in your UI layer. Anything that you can add to describe your data in more details is a good fit for model annotations.

Conclusion

All of the different types of customization that I describe above have useful scenarios that call for them. My suggestion is to get a good understanding of what makes some of them Generic while others are Schema Specific, in order to make an informed decision on the best one to use for your scenarios.

Using Dynamic Data with multiple databases

davidebb — Fri, 12 Dec 2008 05:47:00 GMT

Most Dynamic Data web sites typically only use a single database, with either a Linq To Sql or Entity Framework model over it. But in some cases, you need your site to use multiple databases/models. This came up today in this forum thread. In fact, the original poster (Chris) is the one that came up with a good solution, and that’s what my sample app in this post is doing (so credits to him!).

The full sample is attached at the end, so feel free to get it now if you prefer!

Note that I’ll cheat a little bit, by doing the following:

I’ll only use one Northwind database (bear with me here!)
I’ll create both a Linq To Sql and an Entity Framework model over it

The main reason for doing this is to avoid having to include two MDF files in the sample. There is actually another reason: by using the same DB, we know we’re going to get some name conflicts between the two models, which forces us to make sure that we’re able to handle that case!

Also, the fact that the two models use different ORMs brings up an interesting problem, because normally in Dynamic Data you use a different project template for L2S vs EF. Here, we’re going to want some kind of hybrid. Specifically, what’s different between the two are the Page Templates, since they use different DataSource controls (LinqDataSource vs. EntityDataSource). However, other things like the Field Templates can and should be shared (always avoid duplication when possible!). So we’re aiming for a folder structure that looks like this:

So basically, we keep the DynamicData folder for the shared stuff, and use EF and L2S folders for the different stuff. What they contain is completely unmodified from what you’d find in the default project templates.

The next step it to deal with the routes. Our goal is to use different routes for each model so they don’t conflict. e.g. the URL might look like “L2S_NW/Products/List.aspx” for L2S, and “EF_NW/Products/List.aspx” for the EF model.

Let’s take a look at global.asax, which deals with the two things we just discussed: the folder structure and the route set up. Read through the comments as they cover some important points:

// Keep track of the mapping from db name to MetaModel.  This is used in default.aspx
public static Dictionary<string, MetaModel> Models = new Dictionary<string, MetaModel>();

public static void RegisterRoutes(RouteCollection routes) {
    // Register both models along with their routes
    RegisterContext(routes, "L2S_NW", typeof(NorthwindLinqToSqlDataContext), "~/DynamicData_L2S");
    RegisterContext(routes, "EF_NW", typeof(NorthwindModel.NorthwindEntities), "~/DynamicData_EF");
}

private static void RegisterContext(RouteCollection routes, string dbName, Type contextType, string ddFolder) {
    // Set the Dynamic Data folder to the custom one that was passed in.  However, keep the
    // field templates in the central location since they're the same for EF and L2S
    var model = new MetaModel() {
        DynamicDataFolderVirtualPath = ddFolder,
        FieldTemplateFactory = new FieldTemplateFactory() {
            TemplateFolderVirtualPath = "~/DynamicData/FieldTemplates"
        }
    };

    model.RegisterContext(contextType, new ContextConfiguration() { ScaffoldAllTables = true });

    // Register the route, using the db name as the prefix. Also, we add the db name
    // as a constraint to make sure that we always build the correct URL for a given db
    routes.Add(new DynamicDataRoute("{dbname}/{table}/{action}.aspx") {
        Constraints = new RouteValueDictionary(new {
            action = "List|Details|Edit|Insert",
            dbname = dbName }),
        Model = model
    });

    Models[dbName] = model;
}

Next, let’s look at what needs to happen in default.aspx. Normally, it only lists the tables from one model. Our goal is to allow the model to be selected via a dbname query string parameter. e.g. “Default.aspx?dbname=L2S_NW” or “Default.aspx?dbname=EF_NW”.

First, in the markup, we’ll add a GridView that will act as a model selector, above the existing GridView that lists the tables:

    <asp:GridView ID="ModelMenu" runat="server" AutoGenerateColumns="false"
        CssClass="gridview" AlternatingRowStyle-CssClass="even">
        <Columns>
            <asp:TemplateField HeaderText="Model Name" SortExpression="TableName">
                <ItemTemplate>
                    <asp:HyperLink ID="HyperLink1" runat="server"
                        NavigateUrl='<%#"?dbname=" + Eval("Key") %>'>
                            <%# Eval("Key") %></asp:HyperLink>
                </ItemTemplate>
            </asp:TemplateField>
        </Columns>
    </asp:GridView>

The interesting part here is the Hyperlink databinding, and how it uses the dictionary key. Now let’s see what the code behind has:

protected void Page_Load(object sender, EventArgs e) {
    Dictionary<string, MetaModel> models = ASP.global_asax.Models;

    // Bind the first grid to the list of models
    ModelMenu.DataSource = models;
    ModelMenu.DataBind();

    // If we got a model name from the query string, bind the second grid to its tables
    string dbName = Request.QueryString["dbname"];
    if (!String.IsNullOrEmpty(dbName)) {
        Menu1.DataSource = models[dbName].VisibleTables;
        Menu1.DataBind();
    }
}

Now try running the complete app (attached below). When you first get to default.aspx, you’ll get the list of models. Once you select one, you’ll also see its tables because the dbname parameter is added to the query string.

Then try actually clicking on some of the tables for one of the models, and observe that the URL is only targeting that model (i.e. it starts with EF_NW or L2S_NW).

Hopefully, this gives you an idea of what it takes to use multiple models.

Handling database exceptions in Dynamic Data

davidebb — Fri, 12 Dec 2008 01:53:00 GMT

This post was prompted from a forum thread in which the user wanted to display database errors in a Dynamic Data page, instead of the default behavior that ends up with an unhandled exception (or an AJAX error with partial rendering).

When using Linq To Sql, this can be done fairly easily in a couple different ways, by wrapping the exception in a ValidationException. To do it globally for a DataContext, you can do something like this:

public override void SubmitChanges(System.Data.Linq.ConflictMode failureMode) {
    try {
        base.SubmitChanges(failureMode);
    }
    catch (Exception e) {
        throw new ValidationException(null, e);
    }
}

And to do it with more granularity, you can use one of the partial methods on the DataContext. e.g.

partial void DeleteCategory(Category instance) {
    try {
        ExecuteDynamicDelete(instance);
    }
    catch (Exception e) {
        throw new ValidationException(null, e);
    }
}

A few notes about this:

By passing null as the text, it uses the original exception’s text. You very well may want to use a custom error message instead
Instead of doing it ‘blindly’, you may want to look at the database exception and selectively decide to wrap it or not. If you don’t want to wrap it, just use the ‘throw;’ statement to rethrow it unchanged.
There is a small issue in the default templates that you need to fix if you want to handle DB exceptions happening during a Delete: in both list.aspx and details.aspx, you’ll find CausesValidation="false". You need to either get rid of it or set it to true (which is the default).

But now, let’s try to do the same thing with Entity Framework. Unfortunately, ObjectContext doesn’t have as many useful hooks as Linq To Sql’s DataContext (this will change in the next version), so the techniques above are not available.

However, there is a fairly easy workaround that can be used, which involves using a custom derived DynamicValidator control. Here are the steps to do this (full sample attached at the end of this post).

First, let’s create the derived DynamicValidator, as follows. I’ll let the comments speak for themselves:

/// <summary>
/// By default, Dynamic Data doesn't blindly display all exceptions in the page,
/// as some database exceptions may contain sensitive info.  Instead, it only displays
/// ValidationExceptions.
/// However, in some cases you need to display other exceptions as well.  This code
/// shows how to achieve this.
/// </summary>
public class MyDynamicValidator : DynamicValidator {

    protected override void ValidateException(Exception exception) {
        // If it's not already an exception that DynamicValidator looks at
        if (!(exception is IDynamicValidatorException) && !(exception is ValidationException)) {
            // Find the most inner exception
            while (exception.InnerException != null) {
                exception = exception.InnerException;
            }

            // Wrap it in a ValidationException so the base code doesn't ignore it
            if (ExceptionShouldBeDisplayedInPage(exception)) {
                exception = new ValidationException(null, exception);
            }
        }

        // Call the base on the (possibly) modified exception
        base.ValidateException(exception);
    }

    private bool ExceptionShouldBeDisplayedInPage(Exception e) {
        // This is where you may want to add logic that looks at the exception and
        // decides whether it should indeed be shown in the page
        return true;
    }
}

Then you need to make all the pages use it. The simplest way to do it is via a little know but powerful feature: tag remapping. Here is what you need to have in web.config:

    <pages>
      <tagMapping>
        <add tagType="System.Web.DynamicData.DynamicValidator" mappedTagType="MyDynamicValidator"/>
      </tagMapping>
    </pages>

And then you also need to do the same as the 3rd bullet point above: get rid of CausesValidation="false" in the pages.

And that’s all! You should now see the error messages directly in the page.

Fun with T4 templates and Dynamic Data

davidebb — Thu, 27 Nov 2008 06:18:00 GMT

T4 templates have been a pretty popular topic lately. If you have no idea what they are, don’t feel bad, I didn’t either only a couple weeks ago! In a nutshell, it’s a simple template processor that’s built into VS and allows for all kind of cool code generation scenario. For a bunch of information about them, check out the following two blogs:

The basic idea is that you can drop a hello.tt file into a project, and it will generate a hello.cs (or hello.anything) file via its template. The template syntax of .tt files is very similar to ASP.NET’s <% … %> blocks, except that they use <# … #> instead.

For a cool example of what you can do with T4, check out this post from Danny Simmons, which shares out a .tt which generates all the Entity Framework classes automatically from an edmx file. What’s really nice is that you can easily customize the template to generate exactly the code that you want, instead of being locked into what the designer normally generates.

So how does that have anything to do with Dynamic Data?

One weakness we currently have with Dynamic Data is that we don’t have a great way to get started with a custom page. Suppose you start out with a web app in full scaffold mode, and find the need to customize the Details page for Products. The ‘standard’ procedure to do this is:

Create a Products folder under ~/DynamicData/CustomPages
Copy ~/DynamicData/PageTemplates/Details.aspx into it
Modify the copied file to do the customization you need

While this generally works, it has one big weakness: you need to start your customization from a ‘generic’ file which knows nothing about your specific table. e.g. you start out with a <asp:DetailsView> control that uses AutoGenerateRows to generate all the fields. So if you want to do any kind of real UI customization, you’ll likely have to do a bunch of repetitive steps, e.g.

Get rid of the DetailsView and replace it with a FormView (or ListView) so you can get full control over the layout
In the FormView’s item template, you’ll then need to add one <asp:DynamicControl> for each field that you want to display, along with formatting UI between them (e.g. <tr>/<td>).

A T4 template to the rescue

In a few hours, I was able to put together a quick T4 template that replaces most of those repetitive steps. The steps using this template become simply:

Create a Products folder under ~/DynamicData/CustomPages (as above)
Drop Details.tt into it, and instantly it generates the aspx file, all expanded out with a FormView and all the DynamicControls! This .tt file is attached at the end of this post.

While this is cool, there is one thing that is a bit strange about it: you’re left with a .tt file you don’t want in your project:

And since details.tt file generates details.aspx file, you can’t really change the aspx until you delete the .tt file. Unfortunately, VS makes this more difficult than you would think because the two files are linked to each other. The best steps I found to delete it are:

Right click the .tt file and choose Exclude From Project
Right click the Products folder in open it in Windows Explorer
Delete the .tt file in the explorer
Back in VS, click Show All Files in the solution explorer. You should see the aspx
Now right click it and Include it in the project

I know, that’s painful!! Ideally, what we really want to do is use the .tt do to a one time transform, but never actually have it be part of the project. At this point, I’m not yet sure how to do this, but I’m hopeful that there is a way. Suggestions are welcome! :)

How does the template work?

In order to perform its task, the template needs to figure out what all the entity type’s fields are for the custom page. Doing this is a bit non-trivial, and what I do here is not as clean as it could be, as this is just a quick prototype. Here is a brief description of what it does:

Based on the folder name, it knows what the Entity Set name is (e.g. Products)
It then locates the app’s assembly in bin (caveat: this only works in Web Apps, not Web Sites!)
It copies it to a temp location and loads it from there, to avoid locking the bin assembly
In the assembly, it finds the DataContext/ObjectContext (it handles both Linq To Sql and Entity Framework)
From the context and the entity set name, and can know what the Entity Type is
Once it has that, it knows the fields and can generate the page!

If you look at the t4 files, you’ll see all this logic at the end. That part is certainly quick and dirty, and could use some rewriting. But what comes before it is a pretty clean template that’s easy to tweak to your needs. e.g.

                    <table class="detailstable">
<# foreach (var prop in data.Properties) { #>
                        <tr>
                            <th>
                                <#= prop.Name #>
                            </th>
                            <td>
                                <asp:DynamicControl DataField="<#= prop.Name #>" runat="server" />
                            </td>
                        </tr>
<# } #>
                    </table>

As you can see, it looks very much like inline code in an aspx file, except that instead of executing at runtime on the web server, it executes in Visual Studio to generate a file that becomes part of the project.

What about all the other views?

So I’m only talking about Details.tt/Details.aspx. What about the other Dynamic Data views: List, Edit, Insert? Well, those would all work in pretty much the same way, and I simply haven’t had a chance to get to them. For now, I just wanted to get this first T4 file out as a proof of concept that shows the kind of things that can be done. Contributions are welcome! :)

Conclusion

Clearly, a lot of what I describe here is pretty raw, and it’s only a very early prototype. But I think it should be enough to convey the potential power of design time file generation via T4 templates. Later, I’d like to get better integration with VS. e.g instead of dropping the .tt file in the project and later having to delete it, it’d be nice to get a custom action by right clicking on the CustomPages folder, that would let you generate the aspx file. It would still use T4 under the cover, but you wouldn’t have to see it unless you want to.

Hopefully, I’ll be writing more about this in the future if there is interest.

Using User Controls as Page Templates in Dynamic Data

davidebb — Wed, 26 Nov 2008 05:58:00 GMT

Dynamic Data has the concept of Page Templates, which are pages that live under ~/DynamicData/PageTemplates and are used by default for all tables. Recently a user on the forum asked whether they could use User Controls instead of Pages for those templates.

To me, this means potentially two distinct scenarios, and I tried to address both in this post:

Using routing: in this scenario, you still want all your requests to go through the routing engine, but have the user control templates somehow get used. The URLs here would still look identical to what they are in a default Dynamic Data app, e.g. /app/Products/List.aspx (or whatever you set them to be in your routes).
No routing: in this scenario, you want the URL to go directly to a specific .aspx page, and then have that page do the right thing to use Dynamic Data through the User Control templates.

Creating the User Controls

First, let’s look at what will be the same for both cases. Under ~/DynamicData/PageTemplates, I deleted all the aspx files (to prove that they’re not used), and instead created matching ascx files (i.e. User Controls). Those user controls contain essentially the same things that were in the pages, minus all the ‘outer’ stuff (e.g. things that relate to the master page).

Making it work using routing

Now let’s look specifically at case #1 above, where we want to use routing. First, we need to make a small change to the route to use a custom route handler:

routes.Add(new DynamicDataRoute("{table}/{action}.aspx") {
    Constraints = new RouteValueDictionary(new { action = "List|Details|Edit|Insert" }),
    Model = model,
    RouteHandler = new CustomDynamicDataRouteHandler()
});

Note how we set RouteHandler to our own custom handler type. Now let see what this type looks like:

public class CustomDynamicDataRouteHandler : DynamicDataRouteHandler {
    public override IHttpHandler CreateHandler(DynamicDataRoute route, MetaTable table, string action) {
        // Always instantiate the same page.  The page itself has the logic to load the right user control
        return (IHttpHandler)BuildManager.CreateInstanceFromVirtualPath("~/RoutedTestPage.aspx", typeof(Page));
    }
}

It’s basically a trivial handler which always instantiates the same page! That may look strange, but the idea is that all the relevant information is carried by the route data, which that page can then make use of. Now let’s see what we’re doing in this one page. It’s itself pretty trivial, with just a bit of logic in its Page_Init:

protected void Page_Init(object sender, EventArgs e) {
    // Get table and action from the route data
    MetaTable table = DynamicDataRouteHandler.GetRequestMetaTable(Context);
    var requestContext = DynamicDataRouteHandler.GetRequestContext(Context);
    string action = requestContext.RouteData.GetRequiredString("action");

    // Load the proper user control for the table/action
    string ucVirtualPath = table.GetScaffoldPageVirtualPath(action);
    ph.Controls.Add(LoadControl(ucVirtualPath));
}

The first 3 lines show you what it takes to retrieve the MetaTable and action from the route date. Then the next couple lines load the right user control for the situation. GetScaffoldPageVirtualPath is a simple helper method which has logic to locate the proper ascx:

public static string GetScaffoldPageVirtualPath(this MetaTable table, string viewName) {
    string pathPattern = "{0}PageTemplates/{1}.ascx";
    return String.Format(pathPattern, table.Model.DynamicDataFolderVirtualPath, viewName);
}

And that’s basically it for the routed case!

Making it work without routing

Now let’s look at the non-routed case. Here, the routes are not involved, so the URL goes directly to a page. That page is similar to the one above, but with some key differences. Here is what it does in it Page_Init:

protected void Page_Init(object sender, EventArgs e) {
    // Get table and action from query string
    string tableName = Request.QueryString["table"];
    string action = Request.QueryString["action"];
    
    // Get the MetaTable and set it in the dynamic data route handler
    MetaTable table = MetaModel.Default.GetTable(tableName);
    DynamicDataRouteHandler.SetRequestMetaTable(Context, table);

    // Load the proper user control for the table/action
    string ucVirtualPath = table.GetScaffoldPageVirtualPath(action);
    ph.Controls.Add(LoadControl(ucVirtualPath));
}

The key difference is that it can’t rely on route data being available, so it needs to get the table and action information from somewhere else. You can come up with arbitrary logic for this, but the most obvious way is to just use the query string (e.g. ?table=Products&action=List).

Then it does sort of the reverse of the case above, and sets the MetaTable into the route handler. Even though routing is not used, Dynamic Data tries to get the MetaTable from DynamicDataRouteHandler, so having it there allows many things to just work.

And finally, it loads the user control using the exact same steps as above. And that’s that!

The code is attached below.

ProcessGeneratedCode: A hidden gem for Control Builder writers

davidebb — Thu, 20 Nov 2008 03:57:00 GMT

If you’ve ever written any non-trivial ASP.NET control, you’re probably familiar with the concept of a Control Builder. Basically, it’s a class that you associate with your control and that affects the way your control gets processed at parse time. While ControlBuilder has been around since the ASP.NET 1.0 days, a very powerful new feature was added to it in 3.5 (i.e. VS 2008). Unfortunately, we never had a chance to tell people about it, and a web search reveals that essentially no one knows about it! Pretty unfortunate, and obviously, the point of this post is to change that. :-)

So what is this super cool feature? Simply put, it lets the ControlBuilder party on the CodeDom tree used for code generation of the page. That means a ControlBuilder can inspect what’s being generated, and make arbitrary changes to it.

Warning: this post assumes some basic knowledge of CodeDom. If you are not familiar with it, you may want to get a basic introduction to it on MSDN or elsewhere before continuing.

How do you use this?

To use this feature, all you have to do is override the new ProcessGeneratedCode() method on ControlBuilder. here is what this method looks like:

//
// Summary:
//     Enables custom control builders to access the generated Code Document Object
//     Model (CodeDom) and insert and modify code during the process of parsing
//     and building controls.
//
// Parameters:
//   codeCompileUnit:
//     The root container of a CodeDOM graph of the control that is being built.
//
//   baseType:
//     The base type of the page or user control that contains the control that
//     is being built.
//
//   derivedType:
//     The derived type of the page or user control that contains the control that
//     is being built.
//
//   buildMethod:
//     The code that is used to build the control.
//
//   dataBindingMethod:
//     The code that is used to build the data-binding method of the control.
public virtual void ProcessGeneratedCode(CodeCompileUnit codeCompileUnit, CodeTypeDeclaration baseType, CodeTypeDeclaration derivedType, CodeMemberMethod buildMethod, CodeMemberMethod dataBindingMethod);

So basically you get passed a bunch of CodeDom objects and you get to party on them. It may seem a bit confusing at first to get passed so many different things, but they all make sense in various scenarios.

The CodeCompileUnit is the top level construct, which you would use for instance if you wanted to generate new classes.
Then you have the two CodeTypeDeclarations, which represent the classes that are generated for this page. The reason there are two has to do with how the page is generated. First, there is a partial base class just has control declaration, and gets merged with the code behind class the user writes (in Web Sites, Web Applications are a bit different). Then we derive another class from it, which has the bulk of the code that makes the page run. I know this seems confusing, so let me give you a rule of thumb: when in doubt, use baseType rather than derivedType.
Finally, we have the two CodeMemberMethods, which represent methods that relate to the particular control that’s being built. One is for the method that builds the control (e.g. assigns its properties from the markup, …), and the other one deals with data binding.

Tip to make more sense of all that stuff: a great way to learn more about the code ASP.NET generate is simply to look at it! To do this, add debug=”true” on your page, add a compilation error in there (e.g. <% BAD %>) and request the page. In the browser error page, you’ll be able to look at all the generated code.

How about a little sample to demonstrate?

Let’s take a look at a trivial sample that uses this. It doesn't do anything super useful but does demonstrate the feature. First, let’s write a little control that uses a ControlBuilder:

[ControlBuilder(typeof(MyGeneratingControlBuilder))]
public class MyGeneratingControl : Control {
    // Control doesn't do anything other than generate code via its ControlBuilder
}

Now in the ControlBuilder, let’s implement ProcessGeneratedCode so that it spits out a little test property:

// Spit out a property that looks like:
//protected virtual string CtrlID_SomeCoolProp {
//    get {
//        return "Hello!";
//    }
//}
var prop = new CodeMemberProperty() {
    Attributes = MemberAttributes.Family,
    Name = ID + "_SomeCoolProp",
    Type = new CodeTypeReference(typeof(string))
};

prop.GetStatements.Add(new CodeMethodReturnStatement(new CodePrimitiveExpression("Hello!")));

baseType.Members.Add(prop);

So it just generates a string property with a name derived from the control ID. Now let’s look at the page:

    <test:MyGeneratingControl runat="server" ID="Foo" />

And finally, let’s use the generated property in code. The simple presence of the this tag allows me to write:

Label1.Text = Foo_SomeCoolProp;

And the really cool things is that Visual Studio picks this up, giving you full intellisense on the code generated by your ControlBuilder. How cool is that! :)

Full runnable sample is attached to this post.

What about security?

At first glance, it may seem like this feature gives too much power to ControlBuilders, letting them inject arbitrary code into the page that’s about to run. The reality is that it really doesn’t let an evil control do anything that it could have done before. Consider those two cases:

Full trust: if the Control and ControlBuilder are running in full trust, then they can directly do anything that they want. They gain nothing more from generating code that does bad things
Partial trust: if the Control and ControlBuilder are running in partial trust, then they can’t do much damage themselves directly, and can attempt to do additional damage indirectly via code they generate. However, if the app is running in partial trust (as is typical in hosted environments), then the dynamically generated page code also runs in partial trust. So effectively, it can’t do any more than the control could do directly.

Conclusion

ProcessGeneratedCode is a pretty powerful feature, giving your ControlBuilders full control over the code generation. It’s also a pretty advanced feature, and you can certainly shoot yourself in the foot with it if you’re not careful. So be careful!

A ‘Many To Many’ field template for Dynamic Data

davidebb — Sun, 26 Oct 2008 08:50:00 GMT

Unlike Linq To Sql, Entity Framework directly supports Many to Many relationships. I’ll first describe what this support means.

In the Northwind sample database, you have Employees, Territories and EmployeeTerritories tables. EmployeeTerritories is a ‘junction’ table which has only two columns: an EmployeeID and a TerritoryID, which creates a Many to Many relationship between Employees and Territories.

When using Linq To Sql, all three tables get mapped in your model, and you need to manually deal with the EmployeeTerritories junction table. But when using Entity Framework, the EmployeeTerritories junction table is not part of your model. Instead, your Employee entity class has a ‘Territories’ navigation property, and conversely your Territory entity class has an ‘Employees’ navigation property. What Entity Framework does under the cover to make all this work is pretty amazing!

Unfortunately, in ASP.NET Dynamic Data’s initial release (as part of Framework 3.5 SP1), we didn’t have time to add proper support for such Many to Many relationships, and in fact it behaves in a pretty broken way when it encounters them.

The good news is that it is possible to write a field template that adds great support for this, and that is exactly what this blog post is about. I should note that a couple of our users have written such field templates before (in particular, see this post). In fact, that’s what got me going to write one! :)

One difference is that I set mine out to be completely generic, in the sense that it doesn’t assume any specific database or table. e.g. it works for Northwind’s Employees/Territories (which my sample includes), but works just as well for any other database that uses Many to Many relationships.

In read-only mode, it shows you a list of links to the related entities. e.g. when looking at a Territory, you’ll see links to each of the Employees that work there.

In edit mode, it gets more interesting: it displays a list of checkboxes, one for each Employee in the database. Then, whether the Employee works in this territory is determined by whether the checkbox is checked. Pretty much what you’d expect!

I won’t go into great details about how it works here, but if you are interested, I encourage you to download the sample and look at the code, which I commented pretty well. The key things to look at are:

The field templates ManyToMany.ascx (used for read-only) and ManyToMany_Edit.ascx (used for Edit).
The AutoFieldGenerator, which automatically uses those field templates for Many to Many relationships.

Enjoy, and let me know if you have feedback on this.

Dynamic Data Filtering project up on CodePlex

davidebb — Sat, 23 Aug 2008 03:39:58 GMT

Josh Heyse has just released a very cool extension to ASP.NET Dynamic Data which supports much fancier filtering than is available is the core Dynamic Data. The core idea is that filters can contribute arbitrary LINQ expression trees to the Select query performed by the data source. So for instance you can have a Range filter which checks that a column is between two values, or a Search filter which performs sub-string matching (e.g. StartsWith, EndsWith or Contains). All that is made available with very little effort from the user.

It's all available on CodePlex, so check it out! Start with the included AdventureWorks sample to get an idea what it's all about. Great job Josh!

Using ASP.NET Dynamic Data with ObjectDataSource

davidebb — Thu, 19 Jun 2008 02:37:38 GMT

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>, which allows LINQ to be used on them.

Support for scenarios that use ObjectDataSource

While having this extensibility is great, it doesn't cover a whole range of scenarios where users have their own data layer, with no LINQ and no data context in sight. For a simple example of such scenario, see the sample attached to this MSDN page. The key aspects are:

Entity class: you have a strongly typed some entity class (NewData in the MSDN sample). It just defines the fields you care about, with no real logic attached.
Business layer class: you have a class that has various methods to perform your CRUD operations (the class is named AggregateData in that sample).
ObjectDataSource: your page uses an ObjectDataSource to have ASP.NET interact with your entity and business layer classes. You tell the data source exactly which method to call for each CRUD operation.

Quite a few people use this technique, as it is very flexible and can work with fairly arbitrary business layer.

So how does this all work when you want to use Dynamic Data in this type of scenarios? It actually integrates very nicely, by using some simple functionality that's available as part of the Dynamic Data Futures on CodePlex. If you download that solution, it includes a fully functional sample based on the MSDN sample above.

Here is more details on what it all looks like.

The business layer class

This remains pretty unchanged, except that you have the ability to throw an exception when you see invalid data come in, e.g.

public class AggregateData {

    // Unchanged pieces omitted

    public DataTable Select() {
        return (table == null) ? CreateData() : table;
    }
  
    public int Insert(NewData newRecord) {
        if (newRecord.Name.Length < 3) {
            throw new ValidationException("The name must have at least 3 characters");
        }

        table.Rows.Add(new object[] { newRecord.Name, newRecord.Number, newRecord.Date });
        return 1;
    }
}

Here, it's saying that the name must have at least 3 characters. What's really nice is that the exception you throw here gets shown exactly where you expect it: in the ASP.NET validation summary.

The Entity class

Let's now look at the entity class. Again, it's mostly unchanged from the original, except that we now have the ability to annotate it using Dynamic Data attributes:

public class NewData {
    [RegularExpression(@"[A-Z].*", ErrorMessage="The name must start with an upper case character")]
    [Required]
    [DisplayName("The name")]
    public string Name { get; set; }

    [Range(0, 1000)]
    [UIHint("IntegerSlider")]
    [DefaultValue(345)]
    public int Number { get; set; }

    [DataType(DataType.Date)]
    [UIHint("DateAjaxCalendar")]
    [Required]
    public DateTime Date { get; set; }
}

I won't go over the details of what each attribute means, as they are the standard Dynamic Data attributes and they're fairly self-explanatory. The key point is that everything works exactly in the same way as they would when you use Dynamic Data with Linq To Sql: the rendering goes through the field templates, the UIHint is used to select the template, the validation attributes become ASP.NET validators, ...

The aspx page

Finally, let's look at the ASP.NET page. Again, it's not all that different from the original sample:

    <asp:ValidationSummary ID="ValidationSummary1" runat="server" EnableClientScript="true"
        HeaderText="List of validation errors" />
    <asp:DynamicValidator runat="server" ID="DetailsViewValidator" ControlToValidate="DetailsView1" Display="None" />

    <asp:DetailsView ID="DetailsView1" runat="server" AllowPaging="True" AutoGenerateInsertButton="True"
        DataSourceID="ObjectDataSource1" EnableModelValidation="true">
    </asp:DetailsView>
    
    <asp:DynamicObjectDataSource ID="ObjectDataSource1" runat="server" DataObjectTypeName="DynamicDataFuturesSample.NewData"
        InsertMethod="Insert" SelectMethod="Select" TypeName="DynamicDataFuturesSample.AggregateData">
    </asp:DynamicObjectDataSource>

The most notable change is that ObjectDataSource became a DynamicObjectDataSource, and that we added a DynamicValidator.

So let's see it run!

Here is what it looks like with the above metadata:

Some notable things:

The header for the name says 'the name' thanks to the DisplayName on the Name property
It complains that the name doesn't start with an upper case, per the RegularExpression attribute
The Number's UI shows up as an AJAX slider, thanks to the UIHint
Likewise, the Date UI uses an AJAX calendar

Conclusion

Even though it wasn't a scenario that we originally intended to cover, it turns out that using Dynamic Data with ObjectDataSource scenarios is quite easy and works very well. It really opens up a whole new range of scenarios that don't force users to switch to a different O/R mapper.

It does have a notable limitation: it is not meant to support the full site scaffolding that you get with Linq To Sql or Entity Framework. This comes from the fact that without a data context, there is no easy way to know what the set of relevant tables is, and what relationships they have with each other. Of course, you still get the scaffolding aspect at the page level, in so far as the UI for your DetailsView/GridView is completely model driven, which is the main appeal of Dynamic Data.

One of our users Dan Meineck just blogged about this as well, so check out what he had to say!

ASP.NET Dynamic Data on CodePlex

davidebb — Wed, 18 Jun 2008 10:09:41 GMT

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 preview bits. In order to get the latest preview, you first need to install VS 2008 SP1 Beta. This comes with an outdated build of Dynamic Data, so you then need to install the update from CodePlex. This is the same update that we had on Code Gallery, so if you already installed that, you don't need to do it again.

Once Framework 3.5 SP1 officially ships, there will no longer be a need for this. Note that for all practical purpose, this update is identical to what the final release will be in SP1. We are now completely locked down, and have not made a change in 3 weeks. It just takes a little more time for the whole VS SP1 stack to finish up and be out the door.

Note that even though this is on CodePlex, we are not at this time making the sources of the 'core' Dynamic Data available. I certainly hope that we will be able to in the future, but that has to go through some lawyers and other fun things.

The Dynamic Data Futures

The second important piece that's available on CodePlex is the Dynamic Data Futures (previously calls 'Dynamic Data Extensions'). At this time, these Futures are basically a big VS solution that contain both a library of new features (Microsoft.Web.DynamicData.dll), and a couple web sites that show them in action.

Unlike the Dynamic Data 'core', this 'Futures' piece is fully available in source form. The solution first builds Microsoft.Web.DynamicData.dll, and then builds the various samples that rely on it.

Note that those Futures do not replace the core Dynamic Data, but instead run on top of it. So it shouldn't be looked at as being the 'next version' of Dynamic Data, but rather as being some extra functionality that will be available on top of the Framework 3.5 SP1 release.

This project serves a few different purposes:

It gives us a place to experiment with new features that we didn't have time to put in SP1. Some of those will eventually make their way into the next version of Dynamic Data, while others are likely to remain samples. Obviously, we'd love to get feedback on those (the forum is the right place for that).
It lets us address some issues that are in the SP1 release and couldn't be fixed in time.
It has some great samples for Dynamic Data users to look at and learn how to achieve various results. Note that a few of the samples that were previously separate are now included in there (e.g. Scott Hunter's DbImage sample).

What happens next

The 'Futures' project is very much work in progress, and we are actively adding things to it. So you should expect to see fairly frequent updates on CodePlex.

Please give this a try and let us know how it goes on the forum!