Month: August 2006

I’ve written on the never-ending stored procs vs. ad-hoc SQL debate before, but there are quite a few more perspectives on both sides of it than I referred to in my previous post. Here are a few of them:

• Frans Bouma (ad-hoc SQL camp) compiles a summary post with links to various arguments here.
• Jeremy D. Miller (ad-hoc SQL camp) rejects stored procedures because they make test-driven development (TDD) slower. This is an argument I hadn’t thought of. The apps I build tend to be database-driven websites. Testing logic that makes database calls at any point does slow things down quite a bit. Miller especially dislikes the idea of putting business logic into a stored procedure (defined as anything other than a CRUD operation).
• Jeff Atwood (ad-hoc SQL camp) argues against stored procedures because he prefers parameterized SQL and a single development environment.
• Microsoft’s official guidance is to use stored procedures instead of direct SQL.
• Rob Howard writes in favor of stored procedures.  Community Server 2.1 makes significant use of them.

These arguments make me a lot more curious about object-relational mapping and code generation.

I decided to post on this topic today because of an article I saw on the printer at work this morning. You can check out the entire article yourself here, but what made me decide to post was the author’s assertion that VB.NET can be “considerably less verbose than C#” because of the “with” keyword. He left out the existence of the “using” keyword in C#. The code he writes as an example could be simplified to the following:

using (TabPage tp = tabControl1.TabPages[0]){
tp.BackColor = Color.Red;
tp.BorderStyle = BorderStyle.Fixed3D;
tp.ToolTipText = “Click Me!”;
tp.Text = “Hello world”;
}

In C#, the keyword does double-duty by indicating inheritance from .NET and COM libraries. In VB.NET, another keyword (Imports) is needed for this task.

The author is right about the existence of more automatic formatting and IntelliSense code-completion in VB.NET. However, I consider it more a hindrance than a help when creating properties. In C#, if you want to create a read-only or write-only property, you write the property with just the get block or the set block. In VB.NET, you’re required to provide a ReadOnly or WriteOnly keyword to get the same effect.

The initial reason I decided to learn C# instead of VB.NET is a demo I saw from Don Box at a Guerilla.NET class in 2001. He took a MS Visual C++ sample app and used the .NET Framework to compile it. He didn’t have to change a single line of code to get this to work. He said at the time that this was the only language that trick was going to work for. He turned out to be right.

Early on, another argument in favor of C# was the number of code samples and books. It seemed heavily in favor of C# versus VB.NET, though the gap has certainly narrowed in subsequent years.

A third argument in favor of C# is what language software products are being built in. I heard plenty of rumors in 2001 about Microsoft rewriting some things in C#. But what’s certainly true is that some companies are building products with C#. Writely, a recent acquisition of Google, is written in C#. Community Server, from Telligent, is also written in C#. NUnit, an excellent unit testing tool (ported from JUnit), is also written in C#. NAnt is a C# port of the Ant build tool.

Mine is just one opinion among many as to whether you should use C# or VB.NET. But when there’s a development team involved, the language to be used should be the one the majority of developers are familiar with. That’s why I chose VB.NET when building MethResources.gov even though I personally prefer C#.

Here are some other opinions on the subject:
Choosing between Visual Basic .NET and C# (by Ted Pattison)
From VB.NET to C# and Back Again (by Darren Neimke and Scott Mitchell)

Back in April, at the end of my first post on the topic of “open source .NET“, I’d written that the next post in the series would be about Community Server. Telligent released version 2.1 of their flagship product just last week.

I first found the product at the end of 2004, when it was still Community Server: Forums. My employer was bidding on a project to provide an online forum to one of our government clients. One option they were considering was to make a copy of a custom online forum they’d already done for another client and modify it to suit the new requirements. This option reminded me of two things I dislike most about custom development:

• “Cut-and-paste inheritance“
• Reinventing the wheel–badly

It didn’t take too many Google searches before I found Community Server: Forums and put it forward as an alternative. The next few paragraphs will discuss how I felt the product stacked up against “the four questions”.

1. Is open source the best choice for this application?
Because of how long online forums have been around, open source is a particularly good choice for this application. I came across a pretty large number of options for online forums when I was searching. That said, a number of them were written in languages like PHP or Perl for UNIX (which helps answer question 2).

2. What platform are your developers most skilled at building for?
As a Microsoft shop, trying to deliver a customized solution on a platform the developers weren’t familiar with was far too high a risk. This eliminated a significant number of the applications I’d seen.

3. Is the best open source application on the .NET platform?
In 2004, I would have said no. To me it seemed more likely that the best open source forum application would be on UNIX, simply because of longevity. But given what the developers we had were familiar with, and the alternative of cut-and-paste inheritance with a classic ASP solution, Community Server: Forums was the best for our purposes.

4. Is it our goal to re-sell an application we’ve extended?
Unlike our experience with IssueTracker, the objective of making money with modified versions of this application was clear from the very beginning.

There are two “barriers to entry” with Community Server that proved significant in our case:

• C#
• Documentation

While I had made a deliberate choice to learn C# instead of VB.NET back in 2001, the vast majority of the developers I had to work with had moved to VB.NET from VB. The lack of familiarity with C# syntax led to a number of suboptimal choices for customizing the look, feel, and functionality of a particular instance of Community Server. The relative lack of documentation (both in the source code and stand-alone) made it a challenging platform to extend. I suspect that some of this is by design, as Telligent still makes some portion of their income from custom implementations of Community Server.

On the plus side, Community Server is quite well-built. Its naming and architecture are consistent enough that it took me relatively little time to customize a version of it for my most recent project: pushingback.com. The site is customized in a way that would make it quite easy for us to upgrade the site from Community Server 2.0 to 2.1 if requested. If the companies that currently use it are any indication (Microsoft, Dell, MSNBC), it’s one of the bigger (if not the biggest) successes of open source on the .NET platform.
In my next post on this subject, I’ll discuss an issue that seems unique to open source on .NET–competing products from Microsoft.