Skip to content

Comment on The FogBugz Plugin Architecture

Comments

Instead of having your plugins be able to execute SQL commands, why not use something like ActiveRecord + NHibernate (or some other ORM) with LINQ? NHibernate 2.1 was just released with LINQ support, so you could do something like:

int BugCount = Bug.Where(case => case.Id = caseId).Count();

(Where caseId is a parameter or something). It'd really simplify the API and keep you from doing safety checks on the SQL passed by the plugins. You might even be able to simply some of your "display" code to use Dynamic LINQ queries for the sorting and so forth.

I've been using the ASP.NET MVC + NHibernate + ActiveRecord + LINQ "stack" for several months now (though I've been an ASP.NET developer for about five years), and I have to say that my productivity has gone way up thanks to it.

FogBugz targets .NET 2, which lacks .NET Expressions; they'd have had to build their own AST model, without C# support. I wouldn't be surprised if, whenever FogBugz gets around to requiring .NET 3.5, they start supporting LINQ queries against the exposed datasets, but I wouldn't hold your breath.

Oh, that's too bad. I'm thinking about writing a plugin for FogBugz, and that would have been nice to have (it won't stop me from writing it though ;)

Perhaps they could check out LINQbridge (http://code.google.com/p/linqbridge/). I don't know if that could be adapted to work for them and ease the transition to .NET 3.5, but perhaps its something to look at. (It almost replicates LINQ on the 2.0 framework.)

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.