Experiments In Writing

Visual Studio SP1 and The Metification of REST

2008-08-12T02:39:00Z

Metification – verb

The act of adding metadata to a web service in order to facilitate tooling and discovery.
The act of adding complexity to a web service in order to achieve tight coupling.

Pick one.

Service Pack 1 for Visual Studio 2008 has just arrived with new features, including version 1.0 of ADO.NET Data Services (a.k.a Astoria). From the description (highlighting is mine):

ADO.NET Data Services … consists of a combination of patterns and libraries that enables any data store to be exposed as a flexible data service, naturally integrating with the Web, that can be consumed by Web clients within a corporate network or across the Internet. ADO.NET Data Services uses URIs to point to pieces of data and simple, well-known formats to represent that data, such as JSON and ATOM/APP. This results in data being exposed to Web clients as a REST-style resource collection, addressable with URIs that agents can interact with using standard HTTP verbs such as GET, POST, or DELETE.

Compared to the traditional SOAP approach, the REST-style is a different model for exposing functionality over a web service. Instead of defining messages and exposing operations that act on those messages, you expose resources and act on the resources using common HTTP verbs. I’ve lately been thinking of SOAP based web services as “verb oriented” (exposing GetOrder and UpdateCustomer), while REST style web services are “noun oriented” (exposing Orders and Customers). Both models have advantages and disadvantages, but I’ve felt that REST partners well with rich, Internet applications that need to retrieve a variety of resources using the same filtering and paging parameters. Modeling a heap of GetThisByThat operations using SOAP is tedious.

Noun and verbs aren’t the only difference between REST and SOAP. One of the primary strengths of REST is its inherent simplicity. The simplicity not only facilitates broad interoperability, but encourages an acceptance of REST from many who feel overwhelmed by the complexities of WS-*. There are no tools required for REST - all you need is the ability to send an HTTP request and read the response. WS-*, on the other hand, is great when you need a digitally signed message including double-secret user credentials routed through an asynchronous and distributed, two-phase commit transaction with an extended buyer protection. Not everyone needs that flexibility, but you still pay the price for the flexibility when using the tooling and the API, and when configuring the service.

Although we could continue talking about differences in REST and SOAP, I wanted to talk about metadata, and Astoria.

Metafication

REST proponents, as a rule of thumb, shun metadata – but not all forms of metadata. Metadata in prose or written documentation is fine. Metadata in a self-describing response format is fine. However, metadata for tooling is seen by many as pure evil. Part of the complexity in WS-* is in the quirky and convoluted folds of metadata formats like WSDL and XML Schema. REST has seen some attempts at standardized metadata (WADL, WSDL 2.0, XSD), but still resists all attempts for the most part.

I like metadata. Maybe I’ve been in the .NET ecosystem for so long that I expect tooling, but I still remember the first time I tried to write a program for the Flickr web service (which is technically just POX). I was shocked when I coudn’t find a WSDL file. Then I was surprised at how easy it was to craft the correct URL for an HTTP request, and shred apart the XML response to find photographs. It was so easy that ... well, it was just too easy. It reminded me of writing data access code from scratch. Data access code is so predictable and repetitive that we have tools, frameworks, and code generators to take care of the job. But those tools, frameworks, and code generators rely on metadata defined by a database schema, so their job is relatively straightforward. REST is a bit different, unless you are working with Astoria on the server and a CLR client.

Let’s say you have some DTOs for employees, orders, and other objects you want to send over the wire. You’ll need to decorate them with enough information for the service to understand the primary key.

[DataServiceKey("ID")]
public class Employee
{
   
    public int ID { get; set; }
    public string Name { get; set; }
}
[DataServiceKey("ID")]
public class Order
{
    // …
}

Next, define a class with public IQueryable<T> properties for each “entity set” (Employees and Orders). IQueryable<T> is easy to conjure up, and the class below represents a read-only data source with some fake in-memory data. If you need create, update, and delete functionality the class will need to implement IUpdateable, too. Sean Wildermuth has a three series blog post about IUpdateable that he wrote when implementing IUpdateable for the NHibernate LINQ project.

public class AcmeData 
{
    public IQueryable<Employee> Employees
    {
        get 
        {   return new List<Employee>
            {
                new Employee() /* ... */,
                new Employee() /* ... */,
                new Employee() /* ... */
                // ...
            }.AsQueryable();        
        }
    }

    public IQueryable<Order> Orders
    {
        // ...
    }
    // ...
}

Then you need an .svc file…

<%@ ServiceHost Language="C#" 
    Factory="System.Data.Services.DataServiceHostFactory, 
             System.Data.Services, 
             Version=3.5.0.0, Culture=neutral, 
             PublicKeyToken=b77a5c561934e089" 
    Service="AcmeDataService" %>

… and you’ll also need a code-behind file for the .svc (which is all setup for you using an ADO.NET data service template, you just add some configuration):

public class AcmeDataService : DataService<AcmeData>
{        
    public static void InitializeService(IDataServiceConfiguration config)
    {
        config.SetEntitySetAccessRule("Employees", EntitySetRights.AllRead);
        // ... more rules
    }
}

At this point you can start testing the service using a web browser and looking at, for example, http://localhost/AcmeDataService.svc/Employees. What is more interesting is looking at http://localhost/AcmeDataService.svc/$metadata, because there you’ll find service metadata, which is where the magic starts.

To consume the service, right-click on a project in Visual Studio and select “Add Service Reference…”. Yes – the same “Add Service Reference” command you might have seen in the hit motion picture “SOAP and WSDL – an XML Love Story”. This feature blurs the lines between REST and WS-*. Enter the root URL to the service and Visual Studio will generate a proxy – but not the type of proxy you receive when using SOAP based web services. This proxy will derive from DataServiceContext class and you can use it like so:

var employees = new AcmeData(serviceRoot)
                    .Employees
                    .Where(e => e.Name == "Scott")
                    .OrderBy(e => e.Name)
                    .Skip(2)
                    .Take(2)                      
                    .ToList();

DataServiceContext does a little bit of magic to turn the LINQ query into the following HTTP request. It’s LINQ to REST:

GET /AcmeDataService.svc/Employees()
    ?$filter=Name%20eq%20'Scott'&$orderby=Name&$skip=2&$top=2 HTTP/1.1
User-Agent: Microsoft ADO.NET Data Services
Accept: application/atom+xml,application/xml

The data service will respond with some XML that the data context uses to create objects that look just like the server side DTOs.

I’m sure some are horrified at this metification of REST, but for scenarios when you need to talk between two CLR appdomains (think ASP.NET and Silverlight), this approach gives you the advantages of thinking about nouns in a RESTful model without writing all the glue code to wire up an endpoints and parse XML. Beauty!

Optimizing LINQ Queries

2008-07-14T23:34:00Z

I’ve been asked a few times about how to optimize LINQ code. The first step in optimizing LINQ code is to take some measurements and make sure you really have a problem.

It turns out that optimizing LINQ code isn’t that different from optimizing regular C# code. You need to form a hypothesis, make changes, and measure, measure, measure every step of the way. Measurement is important, because sometimes the changes you need to make are not intuitive.

Here is a specific example using LINQ to Objects.

Let’s say we have 100,000 of these in memory:

public class CensusRecord
{
    public string District{ get; set; }
    public long Males { get; set; }
    public long Females { get; set; }
}

We need a query that will give us back a list of districts ordered by their male / female population ratio, and include the ratio in the query result. A first attempt might look like this:

var query =
    from r in _censusRecords
    orderby (double)r.Males / (double)r.Females descending
    select new
    {
        District = r.District,
        Ratio = (double)r.Males / (double)r.Females
    };

query = query.ToList();

It’s tempting to look at the query and think - “If we only calculate the ratio once, we can make the query faster and more readable! A win-win!”. We do this by introducing a new range variable with the let clause:

var query =
    from r in _censusRecords
    let ratio = (double)r.Males / (double)r.Females
    orderby ratio descending 
    select new
    {
        District = r.District,
        Ratio = ratio 
    };

query = query.ToList();

If you measure the execution time of each query on 100,000 objects, however, you’ll find the second query is about 14% slower than the first query, despite the fact that we are only calculating the ratio once. Surprising! See why we need to take measurements?

Look At Time and Space

The key to this specific issue is understanding how the C# compiler introduces the range variable ratio into the query processing. We know that C# translates declarative queries into a series of method calls. Imagine the method calls forming a pipeline for pumping objects. The first query we wrote would translate into the following:

var query =
    _censusRecords.OrderByDescending(r => (double)r.Males /
                                          (double)r.Females)
                  .Select(r => new { District = r.District,
                                     Ratio = (double)r.Males /
                                             (double)r.Females });

The second query, the one with the let clause, is asking LINQ to pass an additional piece of state through the object pipeline. In other words, we need to pump both a CensusRecord object and a double value (the ratio) into the OrderByDescending and Select methods. There is no magic involved - the only way to get both pieces of data through the pipeline is to instantiate a new object that will carry both pieces of data. When C# is done translating the second query, the result looks like this:

var query =
    _censusRecords.Select(r => new { Record = r, 
                                     Ratio = (double)r.Males / 
                                             (double)r.Females })
                  .OrderByDescending(r => r.Ratio)
                  .Select(r => new { District = r.Record.District,
                                     Ratio = r.Ratio });

The above query requires two projections, which is 200,000 object instantiations. CLR Profiler says the let version of the query uses 60% more memory.

Now we have a better idea why performance decreased, and we can try a different optimization. We’ll write the query using method calls instead of a declarative syntax, and do a projection into the type we need first, and then order the objects.

var query =
    _censusRecords.Select(r => new { District = r.District, 
                                     Ratio = (double)r.Males / 
                                             (double)r.Females })
                  .OrderByDescending(r => r.Ratio);

This query will perform about 6% faster than the first query in the post, but consistently (and mysteriously) uses 5% more memory. Ah, tradeoffs.

Moral Of The Story?

The moral of the story is not to rewrite all your LINQ queries to save a 5 milliseconds here and there. The first priority is always to build working, maintainable software. The moral of the story is that LINQ, like any technology, requires analysis and measurements to make optimization gains because the path to better performance isn’t always obvious. Also remember that a query “optimized” for LINQ to Objects might make things worse when the same query uses a different provider, like LINQ to SQL.

Using an ORM? Think Objects!

2008-07-14T02:40:00Z

I recently had some time on airplanes to read through Bitter EJB, POJOs in Action, and Better, Faster, Lighter Java. All three books were good, but the last one was my favorite, and was recommended to me by Ian Cooper. No, I’m not planning on trading in assemblies for jar files just yet. I read the books to get some insight and perspectives into specific trends in the Java ecosystem.

It’s impossible to summarize the books in one paragraph, but I’ll try anyway:

Some Java developers shun the EJB framework so they can focus on objects. Simple objects. Testable objects. Malleable objects. Plain old Java objects that solve business problems without being encumbered by infrastructure and technology concerns.

That’s the gist of the three books in 35 words. The books also talk about patterns, anti-patterns, domain driven design, lightweight frameworks, processes, and generally how to write software. You’d be surprised how much content is applicable to .NET. In fact, when reading through the books I began to think of .NET and Java as two parallel universes whose deviations could be explained by the accidental killing of one butterfly during a time traveling safari.

The focus of this post is one particular deviation that really stood out.

From Objects To ORMs

The Java developers who focus on objects eventually have to deal with other concerns like persistence. Their object focus naturally leads some of them to try object-relational mapping frameworks. ORMs like Hibernate not only provide these developers with productivity gains, but do so in a relatively transparent and non-intrusive manner. The two work well together right from the start as the developers understand the ORMs, and the ORMs seem to understand the developers.

From DataSets to ORMs

.NET includes includes DataSets, DataTables, and DataViews. There is an IDE with a Data menu, and a GUI toolbox with Data tab full of Data controls and DataSources. It’s easy to stereotype mainstream .NET development as data centric. When you introduce an ORM to a .NET developer who has never seen one, the typical questions are along the lines of:

How do I manage my identity values after an INSERT?

... and ...

Does this thing work with stored procedures?

Perfectly reasonable questions given the data-centric atmosphere of .NET, but you can almost feel the tension in these questions. And that is the deviation that stood out to me. On the airplane, I read about Java developers who focused on objects and went in search of ORMs. In .NET land, I’m seeing the ORMs going in search of the developer who is focused on data. The ORMs in particular are LINQ to SQL (currently shipping in Visual Studio) and the Entity Framework (shipping in SP1). Anyone expecting something like “ADO.NET 3.5” is in for a surprise. Persistent entities and DataSets are two different creatures, and require two different mind sets.

Will .NET Developers Focus On Objects?

It’s possible, but the tools make it difficult. The Entity Framework, for instance, presents developers with cognitive dissonance at several points. The documentation will tell you the goal is for EF to create a rich, conceptual object model, but the press releases proclaim that the Entity Framework simplifies data-centric development. There will not be any plain old CLR objects (POCOs) in EF, and the object-focused implicit lazy-loading that comes standard in most ORMs isn’t available (you can read any property on this entity, um, except that one – you’ll have to load it first).

LINQ to SQL is different. LINQ to SQL is objects all the way down. You can use plain old CLR objects with LINQ to SQL if you dig beyond the surface. However, the surface is a shiny designer that looks just like the typed DataSet designer. LINQ to SQL also needs some additional mapping flexibility to truly separate the object model from the underlying database schema – hopefully we’ll see this in the next version.

What To Do?

If you are a .NET developer who is starting to use an ORM –any ORM, you owe it to yourself and your project to reset your defaults and think differently about the new paradigm. Forget what you know about DataSets and learn about the unit of work pattern. Forget what you know about data readers and learn how an ORM identity map works. Think objects first, data second. If you can’t think of data second, an ORM might not be the technology for you.

LINQ Deep Dive at D.C. ALT.NET Next Week

2008-07-11T05:42:29Z

Matt Podwysocki invited me to speak at the D.C. alt.net meeting next Thursday evening (July 24th). The topic is LINQ. Matt specifically requested a code-heavy presentation, so expect two slides followed by plenty of hot lambda and Expression<T> action.

Hopefully, Matt doesn’t blackout the neighborhood like he did at the nearby RockNUG meeting this week. The White House is two blocks away and the people inside get a little jumpy about blackouts.

DateTime:
7/24/2008 - 7PM-9PM

Location:
Cynergy Systems Inc.
1600 K St NW
Suite 300
Washington, DC 20006
Show Map

Keeping LINQ Code Healthy

2008-07-09T02:40:23Z

In the BI space I’ve seen a lot of SQL queries succumb to complexity. A data extraction query adds some joins, then some filters, then some nested SELET statements, and it becomes an unhealthy mess in short order. It’s unfortunate, but standard SQL just isn’t a language geared for refactoring towards simplification (although UDFs and CTEs in T-SQL have helped).

I’ve really enjoyed writing LINQ queries this year, and I’ve found them easy to keep pretty.

For example, suppose you need to parse some values out of the following XML:

<ROOT>
  <data>
    <record>
      <field name="Country">Afghanistan</field>
      <field name="Year">1993</field>
      <field name="Value">16870000</field>
      <!--  ... -->
    </record>
    <!--  ... -->
  </data>
</ROOT>

A first crack might look like the following:

var entries =
    from r in doc.Descendants("record")
    select new
    {
        Country = r.Elements("field")
                   .Where(f => f.Attribute("name") .Value == "Country")
                   .First().Value,
        Year    = r.Elements("field")
                   .Where(f => f.Attribute("name").Value == "Year")
                   .First().Value,
        Value = double.Parse
                 (r.Elements("field")
                   .Where(f => f.Attribute("name").Value == "Value")
                   .First().Value)
    };

The above is just a mass of method calls and string literals. But, add in a quick helper or extension method…

public static XElement Field(this XElement element, string name)
{
    return element.Elements("field")
                  .Where(f => f.Attribute("name").Value == name)
                  .First();
}

… and you can quickly turn the query around into something readable.

var entries =
    from r in doc.Descendants("record")
    select new
    {
        Country = r.Field("Country").Value,
        Year = r.Field("Year").Value,
        Value = double.Parse(r.Field("Value").Value)
    };

If only SQL code was just as easy to break apart!

Restku

2008-07-08T02:12:00Z

Haiku is a popular poetic form that has evolved over centuries. Restku is Haiku with a twist.

crystal pixels
get brighter
an abundance of excitement

The twist is that the author of a Restku is restricted to using a single verb from this list: get, post, put, and delete. Although traditional Restku insists on present tense usage of the four verbs, adventurous authors will mix in past tense, future tense, and on occasion, present perfect tense.

unexpected dialog
a “progress” bar
vista has posted the bad news

Although Restku was inspired by REST, a software architecture style, there is no reason an author can’t frame concepts from outside the world of information technology into a Restku.

weathered glove
humid skies
put on a childhood dream

Relax your mind with the mental stimulation of writing a Restku today, for tomorrow is still a mystery.

four hundred and four
electrical neurons
delete her memory

Swimming Upstream Is Hazardous

2008-07-03T05:56:09Z

Salmon swim upstream, and look at what happens …

Every developer is familiar with the “work around”. These are the extra bits of extra code we write to overcome limitations in an API, platform, or framework.

But, sometimes those limitations are a feature. The designer of a framework might be guiding you in a specific direction. Take the Silverlight networking APIs as an example. The APIs provide only asynchronous communication options, yet I’ve seen a few people try to block on network operations with code like the following:

AutoResetEvent _event = new AutoResetEvent(false);
WebClient client = new WebClient(); 
client.DownloadStringCompleted += 
    (s, ev) => { _message.Text = ev.Result; _event.Set(); };     
client.DownloadStringAsync(new Uri("foo.xml", UriKind.Relative));
_event.WaitOne();

This code results in a deadlock, since the WebClient tries to raise the completed event on the main thread, but the main thread is blocked inside WaitOne and waiting for the completed event to fire. This deadlock is not only fatal to the Silverlight application, but can bring down the web browser, too. Even if this code didn't create a deadlock, do you really want your application to block over a slow network connection?

When you find yourself writing “work around” code, it’s worthwhile to review the situation. Are you really working around a limitation? Or are you working against the intended use of a framework? Working against the framework is rarely a good idea – there can be a lot of hungry bears waiting to catch you in the future.

Fun with Fills in Silverlight 1.0

2008-02-21T03:33:00Z

I've saw a few people trip over the Fill property of Silverlight objects in JavaScript last week. Let's use the following XAML snippet as an example:

<Canvas>    

    <Rectangle x:Name ="_box1" Canvas.Left="10" Canvas.Top="10"

                Width="100" Height="100" Fill="Red" />

    <Rectangle x:Name ="_box2" Canvas.Left="120" Canvas.Top="10"

                Width="100" Height="100" Fill="Red" />

</Canvas>

Given the way the Fill attributes look (Fill="Red"), you'd be tempted to think the following code would work:

var box1 = silverlightControl.content.findName('_box1');

var box2 = silverlightControl.content.findName('_box2');

box1.Fill = "Green";

box2.Fill = box1.Fill; // this will create an error

But, that last line of code will create a runtime error:

The infamous AG_E_RUNTIME_SETVALUE error! The error says we are trying to put a square object into a round hole. What is the Fill property expecting? Aren't we just copying a simple string reference around? The debugger's immediate window can give us a few hints as to what is happening:

The first dump shows us that the Fill property doesn't reference a simple string. The second dump tells us we are actually dealing with a SolidColorBrush object. Hmmm – what happened to "Red"? Even more mysterious - the third dump (the brush's Color property) is a negative number.

Magical Colors

The MSDN docs for Color describe some of the type conversion magic operating behind the scenes. Essentially, you can set a Color property (or the Fill property of a SolidColorBrush) using a well known name ("Green"), a hex string ('#FF00FF00'), or an ScRGB string ('sc#1,0,1,0'). Silverlight will take care of converting the incoming value into the proper internal representation. So, setting a Color property is easy. What's difficult is getting a meaningful value out of the Color property. Take note of this remark in the MSDN docs:

The runtime scripting value of an existing Color is potentially stored differently on different browsers and platforms. You can compare color values obtained from scripting between existing instances, or set one Color property with the value of another existing Color, but directly comparing these values to named color strings, hex strings, or ScRGB strings that were used to specify the color initially is not supported.

This means we can avoid the runtime error with the following code …

box1.Fill = 'BlanchedAlmond';

box2.Fill.Color = box1.Fill.Color;

… but we need to be careful with code like the following. The makeHexColor function will compute the correct hex string for Color properties on IE7 (like '#ff00ff00' for a green color, which we saw yielded -65536 in the debugger), but according to the docs this code might break in FireFox or on a Mac, because the internal representation of colors might be different.

    box1.Fill = 'Green';

    box2.Fill.Color = makeHexColor(box1.Fill.Color);

    // ...

function makeHexColor(color)

{

    var result = "";

    for (var i = 0; i < 8; i++) {

        result = (color & 0xF).toString(16) + result;

        color >>= 4;

    }

    return "#" + result;

}

Silverlight 1.1 Alpha – An Appetite for Exceptions

2007-11-13T16:18:00Z

The current Silverlight 1.1 alpha will eat exceptions. I’m not sure if the final version will behave similarly, but if you are working with the alpha don’t let this behavior surprise you.

For example, consider the following event handlers that listen to a shape’s mouse events:

void _box_MouseLeftButtonDown(object sender, MouseEventArgs e)

{            

    throw new NotImplementedException();

}

void _box_MouseLeftButtonUp(object sender, MouseEventArgs e)

{

    _box.Width += 5;

}

The left mouse button goes down and … nothing happens. There is no indication of an error.

Later, when the left mouse button goes up … the shape will grow in size. Silverlight is still running with the attitude of a Broadway director. Despite the setback - the show must go on.

If you have some mysterious behavior and are not catching exceptions inside event handlers, a good start might be to go into the Visual Studio Exceptions dialog (Debug -> Exceptions) and configure the debugger to break as soon as code throws an exception (the default setting is to only break on a user unhandled exception). This might help locate the problem.

There is one area where an unhandled exception will stop the show. Consider the following user control:

public class ColorfulSlider : Control

{

    public ColorfulSlider()

    {

        // code ...

        throw new InvalidOperationException("something went wrong...");

    }

}

If we place this faulty user control into a Page.xaml file that loads with the plugin – Silverlight will tell us there is a parser error. The error message tends to make one look inside the .xaml file for malformed XML. The real problem is that Silverlight can’t instantiate the object requested in XAML because the default constructor throws an exception.

The New ASP.NET Framework

2007-10-14T23:19:00Z

The New ASP.NET Framework

ScottGu gave a demo of the new MVC framework for ASP.NET at the ALT.NET Conference. Here are some notes and thoughts I had after watching ScottHanselman's recording.

The framework should go live in the spring of 2008. The framework is not a replacement for ASP.NET WebForms, but provides an alternative paradigm for building web applications. The new framework still works inside of the ASP.NET runtime - meaning all of the wonderful infrastructure pieces like the configuration system, provider model, SQL cache invalidation, health monitoring, and master pages continue to exist. Like the ASP.NET AJAX extensions – it sounds like we'll only need a new assembly to start the party.

Being an "MVC framework", the software features the Model View Controller pattern. MVC and its many permutations have been (and continue to be) principal patterns in many application frameworks and development environments. There were several mentions of Rails (both the Mono and Ruby types), and at least one reference to Django (the Django book is a good read to get into the framework's mindset).

The framework will provide:

Mechanisms to enforce a clean separation of concerns
An API designed for testability
A pluggable and extensible technology stack

Separation of Concerns

ASP.NET WebForms map an incoming URL to a single .aspx file. Although one can use an HttpModule or VirtualPathProvider to change this behavior, the majority of ASP.NET web applications use this default behavior. In practice, this approach tends to produce code-behind files with intermingled presentation, data access, and business logic. This approach also tightly couples URLs to the physical arrangement of .aspx files in the file system.

The new MVC framework offers a loose coupling between incoming URLs and the view that will ultimately render HTML. ScottGu describes a flexible and pluggable URL dispatching engine that can handle clean and procedural URLs like:

http://OdeToCode.com/articles/show/450

http://www.pluralsight.com/classes/register/appliedsilverlight

The URL dispatching engine examines incoming URLs, routes each request to an instance of a controller class, and invokes a method on the controller (the action).

Controllers

Controllers in the new framework support test first and controller first development styles. In other words, you can implement a controller sans any views, and fully test the controller's ability to utilize application logic and services to respond to a request.

The framework provides a low-level interface definition you can implement to claim absolute power over controller policy, but also provides a hierarchy of concrete controller classes to build upon.

When the controller is ready, it can call RenderView(string viewName, object viewData) to generate the appropriate user interface response. Thanks to generics, this boundary can also be strongly typed.

Views

Views render HTML, but views are not web forms - there is no page lifecycle, postbacks, or viewstate in this framework.

In general, views are simple templates. Templates are concerned only with presentation. To enforce a separation of concerns, many template engines do not allow a template to change the value of a variable or call into application logic, but the ASP.NET framework will allow code blocks and data-binding. The view never references a controller, and the controller never references a view - so testability and a separation of concerns prevail.

Designed For Testability

One of the current difficulties in writing unit tests for code running inside an ASP.NET environment is the pervasiveness of sealed classes like HttpContext.The MVC framework features an interface based API with IHttpContext, IResponse, IRequest, etc.

There is a mock view engine and, I believe, mock implementations of IHttpContext and the like to make testing easier.

At the beginning of the discussion Scott mentioned that the framework will include inversion of control containers, although I don't recall this feature appearing in the presentation.

A Pluggable Architecture

It sounds as if every major service in the MVC framework is pluggable – the view engine (throw in Brail), the dependency injection framework (throw in Structure Map), the URL dispatcher, the controllers, and more.

Look For the CTP Soon

The new framework appears to marry mature paradigms from outside the world of ASP.NET with the high performance and robust infrastructure of the ASP.NET runtime. Look for a CTP by the end of the year.

Silverlight Subtleties

2007-10-10T15:18:00Z

Moving from a Silverlight 1.0 JavaScript mindset to a Silverlight 1.1 C# mindset isn't terribly difficult, but there are little traps here and there. For example, to download and display an image, you need to create and configure a Downloader object.

In JavaScript:

var downloader = this.control.createObject("downloader");

downloader.addEventListener("completed", 

    Silverlight.createDelegate(this, this._onDownloaderComplete));

downloader.open("GET", "YodaDog.jpg");

downloader.send();

In C#:

Downloader download = new Downloader();

download.Completed += new EventHandler(download_Completed);

download.Open("GET", new Uri("YodaDog.jpg", UriKind.Relative));

download.Send();

The obvious differences are the wiring of events and construction of the Downloader object. However, the basic patterns in the code are true to their environments and easy to remember. It's the little things that bite you, for instance the Uri passed into the downloader. If the C# version looked like this:

download.Open("GET", new Uri("YodaDog.jpg"));

… then it still compiles and looks like its JavaScript counterpart, but unfortunately doesn't work. We have to explicitly tell the Uri constructor we are passing a relative URI.

The code for getting the downloaded image into an Image control is almost identical.

JavaScript:

_onDownloaderComplete: function(sender, eventArgs)

{

   this._mainImage.SetSource(sender, "");

}

C#:

void download_Completed(object sender, EventArgs e)

{

    this._mainImage.SetSource((Downloader)sender, "");

}

Presto! Yoda dog appears:

But what if we want to take Yoda dog off the screen? The following JavaScript works:

Edit - Oops! The wrong code was pasted here, but is now fixed.

onMouseButtonUp: function(sender, eventArgs)

{        

    this._mainImage.source = null;

},

But the equivalent C# code will leave Yoda dog on the screen*.

void Page_MouseLeftButtonDown(object sender, MouseEventArgs e)

{

    this._mainImage.Source = null;

}

Instead, an empty URI is needed:

void Page_MouseLeftButtonDown(object sender, MouseEventArgs e)

{

    this._mainImage.Source = new Uri("", UriKind.Relative);

}

Of course, the XAML remains the same in both environments.

* Just look at the expression on the dog's face. You know what she is thinking? She's thinking: "Tonight, my owner's favorite shoes become a shredded pile of wet leather…".

Hello, .NET Source Code

2007-10-03T16:43:00Z

ScottGu announced that Microsoft is releasing the source code for the .NET Libraries. The cheering from developers won’t subside for some time. Reflector is a great tool for peering into assemblies, but nothing beats breakpoints and an Immediate Window for seeing what is happening in managed code.

Developers will now be able to reference the implementation of production quality components. Using Windows Workflow as an example, a developer can use the base activity library and WF service implementations as a guide when extending WF.

Looking at the design time implementation of various components in the presentation frameworks will also, I think, be a great advantage.

Is there a drawback? Sure - I can imagine some people wrapping themselves around a tree trying to find a bug in an underlying framework when they really need to be looking at their own code. I know this, because I’ve been guilty of this behavior myself. :)