Web

What's Right About Lambdas and LINQ

Brad Wilson — Sat, 21 Apr 2007 07:55:00 GMT

Two features coming in C# 3.0 are pretty exciting, even though I may have initially (incorrectly) dismissed them a gimmicky.

Lambda Expressions are nice because they are syntactically simpler anonymous delegates, and hands down, anonymous delegates were the best feature of C# 2.0. Generics might've saved us some casts, but anonymous delegates saved us from making whole methods or types, and because they're closures, they eliminate the need for nasty things like passing opaque objects through callbacks. Lambda Expressions make anonymous delegates compact and readable. This was a no-brainer for me.

I was less sure about LINQ. With LINQ Expressions, you can write vaguely SQLish code:

IEnumerable<Person> results = from p in people
                              where p.LastName.StartsWith("G")
                              orderby p.FirstName
                              select p;

or the more explicit:

IEnumerable<Person> results = people.Where(p=>p.LastName.StartsWith("G"))
                                    .OrderBy(p=>p.FirstName);

There are obvious reasons to like this: no chance for SQL injection bugs, don't need to switch your brain from C# mode to SQL mode and back, hiding the simpler differences between database engines, etc.

There's a bigger bang for the buck hiding here, though: it's very likely to make database refactoring dramatically simpler. I like being able to think about all of my database operations in terms of my native development language. Rails does this today with Migrations, and C# 3.0 could benefit from a similar system.

It will really hit the 85% problem well, and then we can build intelligent database refactoring systems that understand how to build migrations as well as modify the query code, without ever having to touch SQL in the process. We can also use static analysis tools to find simple performance issues (missing indices on things that are used in where clauses, for example). The wealth of value that opens up here is almost staggering.

Technorati tags: C# 3.0, Lambda Expression, LINQ, refactoring, agile, database, SQL

Web Developer's Handbook

Brad Wilson — Fri, 19 Jan 2007 08:20:00 GMT

Someone has cultivated an impressive number of links for web developers. Worth bookmarking for the CSSified among us. [found via Pirillo's daily link dump... wait, what do you mean I can't link to an e-mail message!?]

JSON vs. XML

Brad Wilson — Thu, 04 Jan 2007 08:34:00 GMT

Fellow 'softie Dare Obasanjo has a couple great articles on JSON vs. XML: Browser Security Model and Browser Programming Models.

Dare used to work on the XML team here at Microsoft, and is someone I consider more than well enough versed to make the comparison. His conclusions are interesting, because he approaches the problem from a different angle than most (who compare the serialization formats). Definitely very good reads.

Writing Your Own Front Controller for Rails

Brad Wilson — Sun, 09 Jul 2006 17:51:00 GMT

I've been spending the weekend catching up with Rails, and one of the projects I'm working on necessitated that I write my own front controller.

Of course, most people use the Routes system that's built into Rails, which is good enough for the vast majority of applications. However, my URLs are data driven, so maintaining the routes file (and restarting the Rails server) every time I needed to modify the URL space wasn't going to work for me.

I spent the majority of my time finding the right thing to override to get into the request chain. The simplest way seemed to be to override the recognize method in ActionController::Routing::RouteSet, like this: (code from /config/environment.rb)

module ActionController
  module Routing
    class RouteSet
      def recognize(request)
        FrontController.new
      end
    end
  end
end

You can delete all the code from /config/routes.rb, since this avoids the entire route system and forwards all requests to FrontController.

Then I defined FrontController like so:

class FrontController < ApplicationController
  def process(request, response, method = :perform_action, *arguments)
    super(request, response, :index)
  end

  def index
    @req_host = request.env["HTTP_HOST"]
    @req_url = request.env["PATH_INFO"]

    find_controller.constantize.new.process(request, response)
  rescue NameError
    render :file => "public/404.html"
  end

  def find_controller
    # write your code to crack your URL and figure out your controller class
    # return the controller class name as a string
    return "MySpecialController"
  end
end

The find_controller method is where you'll do whatever work you need to crack the URL and figure out what controller you're going to use. The controllers you chain to are defined just like any traditional Rails controller is, including support for rendering views. The call to "constantize" turns the string into an instance of the Class object for the controller class; a new instance of the controller is made, and we call process to chain up the results.

Any modifications you make to request and response will be passed along to the new controller, so you should take the opportunity inside of find_controller to set params[:action] to the name of the action method that you'd like dispatched on your controller class. In my case, I was parsing a whole variety of potential URL spaces (hostnames and paths) to a variety of controller types. The type of the controller depends partially on the prefix of the URL space, and the action may or may not be derived from other portions of the URL.

Obviously, this system has some down-sides. You have to do the URL cracking yourself, and the handy redirect_to() calls with the hash parameters can't reconstruct your URLs for you. However, in my case, it would have been simply impossible to set up static routes to cover everything, so I'm okay with this limitation. I'm using a new base class for my controllers which gives them alternatives to things like redirect_to and link_to.

Adding Templates to ASP.NET 2.0 User Controls

Brad Wilson — Sun, 04 Jun 2006 12:10:00 GMT

Robert Seder has a nice description of adding template functionalty to ASP.NET 2.0 user controls. Found via ScottGu.

Web Application Project Released

Brad Wilson — Tue, 09 May 2006 09:24:00 GMT

The Web Application Project is an add-on to Visual Studio which returns the VS2003 style of web project -- with an explicit project file and free-form directory structure -- while retaining the benefits of VS2005, like the built-in development web server. In my mind, enterprise-level ASP.NET development can reap great benefits from this.

You can download it here.

Mix06 Sessions Online!

Brad Wilson — Thu, 04 May 2006 07:56:00 GMT

All the sessions from Mix06 are online and available, with no registration required. Very cool!

Watching the World Shift

Brad Wilson — Sun, 12 Mar 2006 23:33:00 GMT

In Gosling Didn't Get the Memo, Ryan Tomayko writes:

I believe that a majority of people in IT now consider dynamic languages like Perl, Ruby, Python, and PHP to be very much capable of sitting at the table with Java and .NET for a wide range of common technical problems. Similarly, straight-forward systems like REST, Microformats, and Atom are generally considered legitimate alternatives to the vendor/analyst/press peddled technologies like WS-* for a wide range of integration issues.

This is a very interesting read for people who live solely on the "compiled" side of the fence.