Rob's Blog

There's an awesome tool called LINQPad by Joseph Albahari -- completely free, download here.  ("LINQPad is not an open-source product and the source code is protected by standard copyright laws.  Nonetheless, you are free to disassemble the executable to satisfy your curiosity..." says the author.) 

It's billed as the Query Analyzer for Linq to Sql.  It does wonders for giving you a quick chance to mock up some Linq to Sql.  It is an awesome product for getting you into Linq, but it seems to fall short of it's full potential.

What it does really well:

- Get you to think in LINQ - because you're typing LINQ instead of SQL, you'll get good at LINQ instead of SQL -- that's the goal now-a-days, right?  (: As soon as I get good at == instead of = and && instead of and, I'll let you know... :)

- Quickly mock up some Linq to Sql and see what the answer is.  Discover data, harvest a quick table of results.  The results window is html, so if all you need is the table, copy-paste it into place, and say thank you.

- Samples a plenty - It's hard to know how much I need to type in here.  Do I need a using ( MyDbDataContext db = new MyDbDataContext() ) { ?  What is the data context's variable name?  It turns out LINQPad does all the data context creation behind the scenes, and I only need to spit out the Linq, referencing the tables by name -- very nice.  I wouldn't have figured that out on my own without the Samples tab in the bottom-left pane so eager to greet me.  Many thanks for making that so easy to stumble onto.

- The interface is very well thought out, and very elegant.  Select a db in the same place as I would in Sql Management Studio -- the toolbar on the top.  Browse the databases, tables, and fields in a tree-view as I would in Sql Management Studio.  I can have multiple tabs of queries.  F5 is the shortcut to run the query.  I can look at the raw sql executed by clicking on the [SQL] button above the results pane.  Right-click on a table, and get some sample queries prebuilt for you.  Icons are natural fits.  It is very clean and elegant.  It makes me want to hire Joseph to do interface design.

There are some short-falls though that make it not as effective as it could be:

- No intelisense - the author is very specific about not liking intelisense.  I'm all for freedom of speech and the right to bear arms and legs, but I code faster with intelisense than without.  Yes, I've tried to build intelisense-like, type-ahead, Google Suggest type functionality before.  It is hard.  I don't fault LINQPad for not having it -- especially in a free product, but I find myself typing Linq to Sql easier in Visual Studio and then copy/paste it into LINQPad -- just to get (as Rob Bagby puts it) "the intelisense love".  And if I'm already in Visual Studio, and don't need the bells-n-whistles, I'll just step into the debugger and use the Linq to Sql Query Analyzer.  (Perhaps a mashup product where I can use a VS debugger visualizer to alter the linq query in place the way I can alter variables's values during debugging?  Or embed LINQPad in a window in VS so intelisense hooks and the strongly typed data context for my project are available?)

- No renamed columns and tables - For example, when I built my .dbml file, I spent some time cleaning up where the dba of yesteryear got "creative".  The object name is "student" where the table is "people_who_go_here", the object's property name is "PropertyId" where the table's column name is "ID".  When I do a query in LINQPad, I have to use the old name.  I've been splunking through the Advanced Properties in the Query menu, and it looks like there's a way to reference the .dll my .dbml file is in, and with that, I could perhaps run my new names through LINQPad, but I haven't figured out how to use it yet, and there's no help file.

Summary:

For what it does, it does very well -- a "Linq Query Analyzer".  I think the documentation could be a bit better -- especially in the Advanced Properties windows, but the author has done wonders to make the interface intuitive so documentation isn't necessary.  I'd love intelisense in here, though I know how hard that would be to pull off (and Query Analyzer doesn't have it either without Red Gate).  The interface is gorgeous, intuitive, clean, and feature rich.  Reflecting into both a database, linq code, and pulling off results in a very performant way is just phenomenal -- wish I knew how he did that.  Hats off to Joseph Albahari for a great product.

Scott Guthrie described an awesome Linq to Sql Query Visualizer here.  His context is Visual Studio 2008 Beta 2.  Since then, it's gotten (almost) baked into Visual Studio 2008 RTM.  The functionality is the same, installing it is slightly different.

What is it:

During debugging, show the actual sql that will get executed from your linq query, and allow you to execute the query and see the results -- all within a debugger visualizer.

How to get it:

1. Navigate to C:\Program Files\Microsoft Visual Studio 9.0\Samples\1033  (Modify to suite if you installed Visual Studio 2008 to a different directory.)

2. unzip CSharpSamples.zip

3. Navigate inside the unzipped content to LinqSamples/QueryVisualizer

4. Build the project if necessary.  I chose to change the solution to Release mode, since I likely won't be debugging the visualizer.  :)

5. Copy SqlServerQueryVisualizer\bin\Release\LinqToSqlQueryVisualizer.dll  to C:\Users\<your name here>\Documents\Visual Studio 2008\Visualizers\ (or in XP copy it to C:\Documents and Settings\<your name here>\My Documents\Visual Studio 2008\Visualizers\)

6. Restart Visual Studio 2008

How to use it:

(graphics pillaged from Scott Gu's original post)

1. Create a Linq to Sql query

2. Set a break point after the creation of the Linq to Sql query is formed and before the results are used -- e.g. before the sql is executed.

3. Mouse over the results variable:


4. Click on the magnifying glass:


Welcome to the Linq to Sql Query Visualizer.

Note the "Original query" checkbox on the bottom-left -- if you click it, you'll see how the query is actually parameterized correctly -- no sql injection here.

Note the "Execute" button on the bottom-right -- if you click it, you'll see the results that will get returned into the IEnumerable<T> results var.

In many discussions since, I've heard people describe TSql constructs and syntax they've learned by watching the queries in this window.  I can't wait ... except now that I have Linq to Sql (and Linq to Entities on the horizon), why would I want to code in TSql anymore?  :)

Rob

In ASP.NET AJAX, you create a namespace by calling

Type.registerNamespace('My.Namespace.Of.Choice');

The necessary object dictionaries are built, names resolved, everything is groovy.  But what if you can't use that for what ever reason...

I'm working in a project that can't use the ASP.NET AJAX Client Libraries for reasons that are irrelevant.  I want to create a namespace, so my objects don't collide with others.  The answer turned out to be uber-simple:

var MyNamespace = MyNamespace ? MyNamespace : {};

( idea spurred from an irrelevant post at http://www.lixo.org/archives/2007/09/14/javascript-put-everything-in-a-namespace/ )

Now, I need to do that for each level:

var My = My ? My : {};
var My.Namespace = My.Namespace ? My.Namespace : {};
var My.Namespace.Of = My.Namespace.Of ? My.Namespace.Of : {};
var My.Namespace.Of.Choice = My.Namespace.Of.Choice ? My.Namespace.Of.Choice : {};

After all, a JavaScript "namespace" is just an object, and an object is just a dictionary, and a dictionary just has keys and values.  In effect a JavaScript "namespace" is just a tree of nested object instances that eventually contain my real object.  (see http://odetocode.com/Articles/473.aspx and http://robrich.org/archive/2007/09/16/Object-Oriented-JavaScript.aspx -- yes, I need to blog that better)


Ok, if I want it to be compatible with ASP.NET AJAX Client Libraries, my definition needs to expand to this:

var My = My ? My : function() {
    this.__namespace = true;
    this.__typeName = "My";
}
var My.Namespace = My.Namespace ? My.Namespace : function() {
    this.__namespace = true;
    this.__typeName = "My.Namespace";
};

( see C:\Program Files\Microsoft ASP.NET\ASP.NET 2.0 AJAX Extensions\v1.0.61025\MicrosoftAjaxLibrary\System.Web.Extensions\1.0.61025.0\MicrosoftAjax.debug.js where it defines Type.registerNamespace around line 850 )

or using the prototype model more fully (technically, it's just a single instance of this var, so this is way overkill):

var My = My ? My : function() {}
My.prototype.__namespace = My.prototype.__namespace ? My.prototype.__namespace : true;
My.prototype.__typeName = My.prototype.__typeName ? My.prototype.__typeName : "My";

My.Namespace = My.Namespace ? My.Namespace : function() {}
My.Namespace.prototype.__namespace = My.Namespace.prototype.__namespace ? My.Namespace.prototype.__namespace : true;
My.Namespace.prototype.__typeName = My.Namespace.prototype.__typeName ? My.Namespace.prototype.__typeName : "My.Namespace";

Suddenly I'm very grateful for all the work that went into the ASP.NET AJAX Client Libraries that I don't need to do...


On a similar but completely different note, if you're just insuring names don't collide, a technique of wrapping your whole code block in an anonymous function works nicely ( source: http://ajaxcookbook.org/javascript-api-namespaces/ )

The technique involves putting (function(){ before your code and })(); after it.  Your whole block of code is now a function that's executed once, then goes out of scope.  Ok, if you don't declare your var inside the function, and you happen to name it identically to a neigboring var, I could see collisions, but likely you're all-but safe.

Rob