ASP.NET Ninjas On Fire Black Belt Tips

Demo-heavy Haack talk on ASP.NET MVC:

• CSRF
• Unit Testing
• Model Binders
• Concurrency
• Expression Helpers
• Custom Scaffolding
• AJAX Grid
• Route Debugger

The first demo started with Haack writing a bank site. A topic close to my heart. And it’s for CSRF protection, which is also interesting.

The [Authorize] attribute on a controller means anyone accessing the controller method needs to be authenticated. Cool.

OK, so the demo is showing a cross-site request forgery on a POST request. You apply a [ValidateAntiForgeryToken] attribute on the controller action and in the form you put a hidden form field with a random value associated with your session using the Html.AntiForgeryToken method. This appears to me to be the MVC answer to ViewStateUserKey and ViewState MAC checking. If the POST is made without the token, an exception is thrown. I was talking to Eilon Lipton at the attendee party a couple of nights back and confirmed that only POST requests can be protected. The problem there is that if the browser is insecure and allows the attacker to create a cross-domain GET to retrieve the form and inspect the results of that GET, then it can grab the anti-forgery token, add it to the POST, and it will succeed. (This is the same case with ViewState MAC checking in web forms.) A full CSRF protection mechanism covers every request, not just select ones. I’ll have to see if I can get that pushed through into MVC. (That would be a pretty compelling solution to get us to switch away from web forms/MVP.)

Next demo is how to do a controller action unit test. I got this one. Should be using Isolator for mocking, though. :) Showed some good patterns for folks who are unfamiliar with them, though - TDD, dependency injection, repository pattern… valuable stuff to get the community thinking about. Might have been just a liiiittle too fast for some of the folks unfamiliar with the patterns, though.

Next demo is model binding. The [BindAttribute] lets you specify which fields posted to the controller action should be used when populating the action’s parameters. I think more time should have been spent on this because model binding is actually pretty interesting. (Maybe I missed this in the latter half of yesterday’s talk.)

Concurrency. That is, two people editing the same record through the web interface at the same time. The tip here used a timestamp in the database using the “rowversion” data type and setting the “Update Check” value to “true” on that column. When you try to submit an update to the record, it’ll check to see if the row version you’re sending in is different than the one on the actual record in the database. If they’re different, you know the record has changed since you started editing and you throw an exception; if they’re the same, you’re good to go.

He’s using stuff from the “Microsoft.Web.Mvc” assembly - the MVC Futures assembly

• which isn’t part of the RTM that was announced this week. Not sure I’d be demoing stuff that doesn’t ship… but I understand. Now I’m curious to see what’s in the Futures assembly besides the base64 encoding method he’s showing. (Futures is hard to find on CodePlex. Look for the MVC “source” release - you’ll find it there.)

One of the most confusing things about the [HandleError] attribute is that if you’re using it on localhost, it has the same semantics as the CustomErrors section in web.config. If you want to see the [HandleError] attribute work, you need to set web.config correctly.

MVC Futures has “expression-based helpers” to render controls based on your model using lambdas. Instead of: <% Html.TextBox(“Title”, null, new {width=80}) %> you can use: <% Html.TextBoxFor(m => m.Title, new {width=80}) %> Nice because of the strong typing.

In order to move from string-based to expression-based binding, you need to override the T4 templates that generate the default views. Putting your overrides in your project in a CodeTemplates/AddController or CodeTemplates/AddView folder will get the project to override the defaults for that project. You’ll need to remember to remove the custom tool from the .tt templates or it will try to generate output for them. You can even add your own custom .tt templates in there so when you do File -> New Controller or whatever it will show up in the dialogs.

If you’re doing a lot of T4 editing, the Clairus VisualT4 editor looks nice. It adds syntax highlighting for T4 into Visual Studio. Not sure I’d have included that in the demo, though, since it’s not what the lay-user is going to see.

“Validation in ASP.NET MVC is a little tricky because we don’t have built-in support for DataAnnotations.” There’s an example on CodePlex for this. I’ve played a bit with DataAnnotations and I’m not overly won-over. You have to add a partial class to “extend” your data object, put the [MetadataType] attribute on that and point to a “buddy class,” then create another class that has properties all of the same name as the data object that you want to annotate. Something like this:

[MetadataType(typeof(Question.Metadata))]
public partial class Question
{
  private class Metadata
  {
    [Required]
    [StringLength(10, ErrorMessage="Too long.")]
    public string Title { get; set; }
  }
}

(This is how Dynamic Data does it.) Apparently there’s some way coming out where you can specify that metadata through XML rather than attributes. I think I’ll be more interested when that comes out.

Nice tip here, instead of specifying an error message in your annotation, you can specify a resource. That’s key, since we have to localize everything.

[MetadataType(typeof(Question.Metadata))]
public partial class Question
{
  private class Metadata
  {
    [Required]
    [StringLength(10,
                  ErrorMessageResourceType=typeof(Resources),
                  ErrorMessageResourceName="TitleVerboseError")]
    public string Title { get; set; }
  }
}

Finally, a demo that shows something more complicated around validation. Now to see a demo where the validation parameters aren’t static…

Route debugging. Haack has posted a nice route debugger that puts up a page that shows the various routes in the table and which route was matched based on the incoming URL. Very helpful if you’re having a tough time figuring out why you’re not getting to the controller action you think you should be getting to.

We skipped the demo for the jQuery AJAX grid. He’ll show that in an open space later if you want to see it.

There’s a Little Scripter in All of Us

This is Rob Conery’s challenge to the audience to embrace their inner scripter and move away from the “architecture astronauts.”

First point is the acronyms we get into with ASP.NET. TDD, DRY, KISS, etc. Can we break the rules that ASP.NET generally leads us to? “Not everything is an enterprise app.” Hmm. This is going to be a little interesting for me since I’d actually like to see MORE focus on enterprise app development in ASP.NET. It’s like ASP.NET is hovering in this limbo area where it’s not fully set for enterprise development, but it’s also more than tiny scripting sorts of apps need. Makes me wonder if it’s trying to be too much. Jack of all trades, master of none.

Lots of apologies for the demo. “I’m on a Mac and the tech here doesn’t like it. The CSS on the demo doesn’t like a 1024 x 768 resolution so it looks bad on the screen.” As an audience member I don’t care, I just want to see it working and looking good.

He mentions that he jammed together a truckload of reeeeeally bad JavaScript code to get the MVC Storefront to work. “If I showed you that code, you’d probably throw up. Do I care?” Hmmm. This is getting harder for me to swallow. “Success as a metric” only works if you don’t have to go back and maintain the app, fix bugs, or add features. Oh, or if your team never changes. Just because it works doesn’t mean it’s right.

Oh, there’s another apology. “OpenID should be showing up down there… but I don’t have network connectivity.” Demo FAIL. With all the stuff not working, it’s really not convincing me that the rapid scripter approach to things is the way to go.

Bit of a backtrack - “I’m not giving up on architecture.” Showed some data access stuff - repository pattern, state pattern. Okay… and then we get to see the massive amount of inline script in the view. Wow. My head a-splode.

Here’s the point, I think: He showed this application he downloaded that had like 20 assemblies and when it didn’t work… it was so complex it was impossible to troubleshoot. The architecture might have been great, but it’s not something you could just download and get going. With a flatter application you might have a less “correct” architecture, but it might also be easier to get up and running and in front of the eyes of your users. That, I will buy. Granted, you have to take it with a grain of salt - if you’re making a massive distributed system that has certain scalability and deployment requirements, yeah, it’s going to be complex. On the other hand, if you’re just “making a web site,” you might not need all that. He kind of took it from one far end of the spectrum to the other (which made it a hard sell to me) but I get the idea.

Crap. Battery’s dying. Time to plug in.

Building Microsoft Silverlight Controls

I’ve not done a lot of Silverlight work so seeing this stuff come together is good. The lecture is in the form of building a shopping site using Silverlight. I got here a little late (was eating lunch) and the topic is setting up styles in a separate XAML file (StaticResources). Sort of like CSS for XAML. Good.

The clipboard manager the presenter is using is kind of cool. Curious what it is. Looks WPF.

So, new styling stuff in Silverlight 3 - “BasedOn” styles, so you can basically “derive and override” styling. Also, “merged dictionaries” so you can define styles that are compilations of mulitple styles. (Not sure I described that last one well. There was no demo and it was skimmed over.)

Skinning works with custom controls but not user controls or panels. The reason for this is that custom control visuals are in a <ControlTemplate> in XAML and all of the control logic is in code - good separation. User controls, I’m gathering, are more tightly coupled.

“Parts and States Model” - Make it easy to skin your control by separating logic and visuals and defining an explicit control contract. It’s a recommended pattern but is not enforced. “Parts” are named elements (x:Name) in a template that the code manipulates in some way. “States” are a way for you to define the way a control should look in the “mouseover” state or the “pressed” state. You define these with <VisualState> elements. Not all controls have states. “Transitions” are the visual look your control goes through as it moves between states and are defined with a <VisualTransition> element. “State gropus” are sets of mutually exclusive states and are defined in <VisualStateGroup> elements. (I’m gathering that the demo here will show this all in action.)

The demo is making a validated text box. Styling of the textbox is done using {TemplateBinding} markup so if someone sets various properties on the text box they can change the style. Another “part” of the text box is the place where the text goes and… oh, she moved too fast. Somehow by calling that element “ContentElement” using x:Name attribute the text magically showed up in the text box. We saw a VisualState setup where the mouseover for an element on the text box would enlarge the element (a little star, when the mouse isn’t over it, would get twice its original size in mouseover state). Using VisualTransitions, she animated the transition between the two states so it looked nice and smooth.

The default binding for a text box is, apparently, that whenever the user tabs away, that’s when the “onchanged” event happens. In Silverlight 3 they let you set the binding to be explicit (it will never automatically happen) and then you can add a KeyUp event handler that lets you do the binding every time a key is pressed. Nice. (Seems a little roundabout, but I’m gathering this is a big improvement from Silverlight 2.)

Out of the box, Silverlight 3 will have good, standard-looking validation UI. TextBox, CheckBox, adioButton, ComboBox, ListBox, PasswordBox. Good. I think we’re fighting validation right now in one of our projects.

I haven’t used Blend a lot before, but I have used Photoshop, Illustrator, AutoCAD, and 3DSMax. Those are listed in order of UI complexity (my opinion based on my experiences with them). Blend seems to fall somewhere between Illustrator and AutoCAD. The demo of hooking up states in Blend is interesting, but… well, not really straightforward. If someone grabbed me right after this there’s no way I could repeat it.

“The coolest and least interesting demo” for people who have used Silverlight 2 - They’ve enabled the ability to change the style of elements at runtime. I’m gathering that wasn’t possible in previous versions. The demo looked basically like a demo that uses JS to change CSS on some HTML at runtime. Glad Silverlight can do… uh… the same thing DHTML has been able to do for years.

Next demo is creation of a custom control showing the control’s contract (attributes that define the various states the control can be in) and the manner you programmatically track the control’s state. The default style for your control should be in “generic.xaml” and needs to be included in the Themes namespace of your control assembly as an embedded resource. The custom control created was a five-star “rating” control like you’d see on Netflix or Amazon. Cool.

A lot of the way this seems to work is reminiscent of trying to deliver packaged user controls. The markup (ASCX in user controls, XAML for these Silverlight controls) may or may not have all of the controls they should because the designer may or may not have included them all, so you have to check to see if the nested controls even exist before acting on them.

Just about time for the final session of the day.

Building High-Performance Web Applications and Sites

The tips here should help in all web browsers, not just IE, but specific stats will be in IE (since it is given by an IE team member).

In the top 100 sites online (don’t know what those are), IE spent 16% of its time in script but the rest in layout. In AJAX-heavy web sites, it only increased to 33% in script. Most time is spent in layout and rendering.

CSS performance.

• Minimize included styles. Unused styles increase download size and rendering time because failures (CSS selectors that don’t point to anything) cost time.
• Simplify selectors. Complex selectors are slow. Where possible, use class or ID selectors. Use a child selector (ul > li) instead of a descendant selector (ul li). Don’t use RTL and LTR styles. Minimizing included styles makes this easier.
• Don’t use expressions. They’re non-standard and they get constantly evaluated.
• Minimize page re-layouts. Basically, as the site is dynamically updating or the user’s working on things, you want to minimize the amount of things tha update. The example here was a page that dynamicaly builds itself and inserts advertisements as they load… and things jump all over the place. When those sorts of changes happen, the browser has to re-layout the page. A better approach for this would be to have placeholders where the ads are so the page doesn’t re-layout - content just gets inserted and things don’t jump around.

Optimizing JavaScript symbol resolution… Lookups are done by scope - local, intermediate, global - or by prototype - instance, object prototype, DOM. If you can optimize these lookups, your script will run faster. One example showed the difference between using the “var” keyword to declare a local scope variable and forgetting the keyword - if you forget the keyword, the variable isn’t local so the lookups get longer. Another example was showing repeated access of an element’s innerHTML property - rather than doing a bunch of sets on the property, calculate the total value you’re going to set at the end and access innerHTML once. Yet a third example showed a function that got called in a loop - every time it runs, the symbol gets resolved. Making a local scope variable function pointer and resolving the symbol once is better.

Of course, you only want to do this sort of optimization when you need to, but how do you know if you need to? There are various JS profilers out there, and the presenter showed the one in IE8 which is pretty sweet and easy to use. I haven’t gotten so far into JS that I needed to profile, but it’s nice to know this sort of thing is out there. Anyway, the interesting point of this part of the demo was showing that optimizing some of the lookup chains (in these simple examples) reduced some execution times from, say, 400ms to 200ms. I guess VS2010 will have this built in.

JavaScript Coding Inefficiencies.

• Parsing JSON. You do an AJAX call, get some script back and need to turn it into an object. How do you do it? With “eval()” it’s slow and pretty insecure. In a third-party parsing library it’s slower but more secure. The ideal solution is to use the native JSON parsing methods JSON.parse(), JSON.stringify(), and toJSON() on Date/Number/String/Boolean prototypes. This is in IE8 and FF 3.5.
• The switch statement. In a compiled language, the compiler does some optimization around switch/case statements. Apparently in JavaScript, that optimization doesn’t happen - it turns into huge if/else if blocks. A better way to go is to make a lookup table surrounded by a try/catch block where the catch block is the default operation. Definitely want to run that through the profiler to see if it’s worth it.
• Property access methods. Instead of getProperty() and setProperty(value) methods (which makes for clean code), just directly access the property backing store directly. Skip the function call and added symbol resolution.
• Minimize DOM interaction. As mentioned above, the DOM is the last place that’s looked to resolve symbols. The less you have to do that, the better. (DOM performance has improved, apparently, in IE8.)
• Smart use of DOM methods. For example, use nextSibling() rather than nodes[i] when iterating through a node list. These methods are optimized to be fast. The querySelectorAll method, new in IE8, is optimized for getting elements by CSS class selectors and can be faster than getElementById or iterating through the whole DOM to find groups of elements.

Through all of this, though, optimize only when needed and consider code maintainability when you do optimize. You don’t just want to blindly implement this stuff.

HTTP Performance. This is a lot of that YSlow stuff you’re already familiar with.

• Use HTTP compression. Whenever you get a request that says it allows gzip, you can gzip the response. You only want to do this on text or other uncompressed things, though - you don’t want to compress something like a JPEG that’s already compressed. If you do, in some cases, the download to the client might actually get bigger and you’ve wasted both client and server cycles in compressing/decompressing that JPEG.
• Scaling images. Dont use the width/height tags on an image to scale it down - actually scale the image file.
• File linking. Rather than having a bunch of JS or CSS files, link them all together into a single CSS and a single JS file. You’ll still get client-side caching, but you’ll reduce the number of requests/responses going on.
• CSS sprites instead of several images. Say you have a bunch of buttons on a toolbar. You could have a bunch of images - one image per button… or you could have one composite image and use DIVs and CSS to show the appropriate portion of the compositie image on each button.
• Repeat visits. Use conditional requests - use the Expires header in a response so the browser knows if it can get the item out of local cache.
• Script blocking. When a browser hits a <script> tag the browser stops because it doesn’t know if it’s going to change the page or not. Where you can, put the <script> at the bottom of the body so it’s loaded last. This is improved in IE8, but it’s still there.

IE8 has increased the connections-per-domain from two to six by default. No more registry hacking to get that to work.

Tools

• Fiddler - inspects network traffic.
• neXpert - plugin for Fiddler to aid performance testing.

And that’s all, folks. Battery’s dead and the conference is over. Time to fly home!