Scott Hanselman

There's lots of interesting stuff going on in the ASP.NET team, and you can usually learn/glean/figure out most of it (if you're interested) by poking around the Codeplex ASP.NET site. They update it all the time, and you can watch their thinking. They put all sorts of stuff up there, ideas they are floating, directions they are considering and (really early) previews of those ideas and directions in the form of code. It's not production ready, more brainstorming - that's why it's on CodePlex, and why they don't exactly advertise the heck out of it.

There's a release of ASP.NET Dynamic Data 4.0 Preview 2 that was quietly put up just a month ago with this scary disclaimer:

NOTE: These previews contains features that may not be in the next version of the framework. These previews are not production quality and should be used at your own risk.

Dynamic Data 4.0 Preview 2

Let's poke around the SampleProject Solution that's included with this preview download. There's five projects showing off a number of new feature possibilities.

• BusinessLogicDataSource – A showcase for a new BusinessLogicDataSource that combines customizability of ObjectDataSource with the flexibility of LINQ and the IQueryable interface. Also, a new QueryExtender feature allowing high-level query composition in markup is demonstrated.
  I don't really like the name for this (at all) but it's brainstorming at this point.
• DataServicesServer and DataServicesClient - illustrates the use of ADO.NET Data Services with Dynamic Data. This is the stuff I think is really interesting and what I'll focus on in this post.
• DynamicDataFuturesSample - contains the existing Dynamic Data Futures sample that has been available. This sample does not add any new functionality in comparison to the old Futures project except for running on new Dynamic Data assemblies.
• SampleProject – Shows the next generation of Dynamic Data features including support for Entity Framework and Linq to SQL inheritance, many to many support for Entity Framework, Entity templates and the new templated filters that are based on the QueryExtender.

The two I'm interested in are the DataServicesServer and Client.

Quick Review

Before I talk about them, let's review some of the things we can, as developers, choose from in .NET 3.5 on the Data side. You've got lots of choices:

• Linq to SQL (Server): If you don't mind your objects being nearly 1:1 with data model, it's fast and easy to use. Stackoverflow.com uses it. Some folks are freaking out thinking it's "dead." But I think that's silly. More on that later. I use it all the time. Know what it can do, know what it's not good for.
• Entity Framework: If you want more control over what your Data Access Layer (DAL) objects look like, and there's not a 1:1 relationship between your objects and the database. If you are using not just SQL Server, but other databases like Oracle, etc.
• Your own thing: Lots of folks write their own DALs with DataReaders loading objects, etc. I used to do this with CodeSmith generating all the boring stuff.
• NHibernate (OSS): Define your Domain, define a mapping (from a number of possible ways) and configure.
• Subsonic: Can be used two ways, as an regular ORM (Object Relational Mapper) or as a no-code DAL provider.

On the Web side, you can make your "angle-brackets" and HTML UIs ;) a number of ways:

• ASP.NET Web Forms - Programming the web with a controls and event model.
• Classic Demo: Drag a grid, drag a data source, setup some binding markup. Boom, page.
• ASP.NET MVC - Testable, extensible. Control over your markup and your programming model.
• Classic Demo: Write a test, fail, fix, pass. Create a model, create a view, hook up the controller. Boom, page.
• ASP.NET Dynamic Data - Dynamically generating sites using templates over a meta-model.
• Classic Demo: File | New ASP.NET Dynamic Data site. Let it know about your Data Context. Edit the templates to test. Boom, site.

If you aren't generating UI angle-brackets, but rather data-specific angle-brackets, like XML, or even JSON, you can use:

• ADO.NET Data Services (codename: Astoria): You can take any IQueryable objects and get a nice AtomPub/REST Web Service interface based on WCF (Windows Communication Foundation). This isn't a database-specific technology; you can make data services just with List<MyObject>. Anything with a LINQ provider can be a service. Astoria is a great way to take a client application that may have needed direct database access and turn it into an app that talks HTTP over Port 80. It's also a great way to get JSON back for your jQuery ajax() calls or by using ADO.NET Data Services direct Javascript support.

Mix and Match

For the most part, you can happily mix and match these different technologies as much as you like. That means you can use ASP.NET MVC with NHibernate, or Web Forms with Subsonic.

Some have some requirements, usually an interface to implement or a provider to provide. For example, if you have an IQueryable (LINQ) implementation, you can use ADO.NET Data Services. If you've got LINQ for Subsonic, you get ADO.NET Data Services for free. If you want Updates, you implement IUpdateable. (Here's a LINQ to SQL IUpdateable implementation, and why you should care.)

However, ASP.NET Dynamic Data does a LOT of stuff for you. It needs a complete "meta-model" populated that describes the data and needs to understand how to update that data. It's pretty specific to the underlying database (or ORM, or whatever) technology, so you need a provider that is specific. That DataModelProvider (and a few others) get the metadata from your source and pass it to ASP.NET Dynamic Data. ASP.NET 3.5 SP1 ships with providers for Entity Framework and Linq to SQL.

You could implement your own, if you have an existing database/access technology. Someone could write some NHibernate or Subsonic providers, then get all the Dynamic Data stuff to sit on top.

I really like keeping my websites from having direct access to the database, at least when I'm doing big Enterprise work. One of the rules the security guys always drilled into us was to assume that the web server has already been compromised. Basically, assume they (the baddies) OWN (or PWN) it, and code appropriately. There's a number of ways to do this, but one way to limit access to your database is to create a very limited Web Services/REST interface to be called from the Web Server.

Back to ASP.NET Dynamic Data. There's no provider that lets you point ASP.NET Dynamic Data to a ADO.NET Data Service...except there is in this preview.

The Preview Projects - DataServicesClient and DataServicesServer

If you check out the web.config of the DataServicesClient project, you can see he's added client-side assembly redirects to force the loading of his private builds of two assemblies:

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
      <assemblyIdentity name="System.ComponentModel.DataAnnotations" publicKeyToken="31bf3856ad364e35"/>
      <bindingRedirect oldVersion="3.5.0.0" newVersion="99.0.0.0"/>
    </dependentAssembly>
    <dependentAssembly>
      <assemblyIdentity name="System.Web.DynamicData" publicKeyToken="31bf3856ad364e35"/>
      <bindingRedirect oldVersion="3.5.0.0" newVersion="99.0.0.0"/>
    </dependentAssembly>
  </assemblyBinding>
</runtime>

There's two changed files with the goofy build number of 99.0.0.0. Those are preview DLLs. After this, it  looks pretty much like a standard Dynamic Data ASP.NET site.  There's a client-side DataContext generated from a standard, unchanged, ADO.NET Data Service and it gets registered in the Global.asax:

MetaModel model = new MetaModel()
model.RegisterContext(
    new DataServiceDataModelProvider(
       typeof(NORTHWNDModel.NorthwindClientEntities)),
    new ContextConfiguration() { ScaffoldAllTables = true });

The Dynamic Data system gets all its meta-model information from the DataServiceDataModelProvider pass in there. It's currently in Microsoft.Web.Misc.dll along with some other very telling (at least at the time, but surprising no one noticed) stuff like "RedDogDataServiceContext" and "SDSDataServiceContext." (The last one is a silly name, expanding to SQL Data Service Data Service Context. ;) )

But not just Dynamic Data, WebForms, too

In the DynamicData Templates, there's a reference to a new DataSource control called DataServiceLinqDataSource. That's included in this preview. This is cool because it not only hooks up nicely to the templates, but it can be used outside Dynamic Data. You can use it in Web Forms just like this using a ListView or GridView or whatever.

<asp:GridView ID="GridView1" runat="server" DataSourceID="GridDataSource"
    AutoGenerateEditButton="true" AutoGenerateDeleteButton="true"
    AllowPaging="True" AllowSorting="True">
</asp:GridView>

<asp:DataServiceLinqDataSource ID="GridDataSource"
    ContextTypeName="NORTHWNDModel.NorthwindClientEntities" TableName="Products"
    runat="server" EnableDelete="true" EnableUpdate="true">
</asp:DataServiceLinqDataSource>

This way you can use ADO.NET Data Services wherever. In markup, in code-behind, in Dynamic Data sites, or some combination of them all - staying off the database directly and talking REST (AtomPub) Web Services instead from you Web Services, so you go from this:

To this:

Again, bask in the wonderful Paint-y ness of my lovingly created high-quality diagrams.

I personally think that this is an important addition and fills a hole. If you agree and think it should be a part of something in the future, tell Scott Hunter (crush him with email!) the Program Manager for ASP.NET Dynamic Data. He put this release up for feedback, so contact him if you've got ideas, comments or feel strongly about something. Or leave a comment here and I'll tell him.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By