# Friday, May 29, 2009

LinqToSql does offer benefits to corporate IT organizations.  Microsoft marketing has helped spread that message.

It's less clear what the drawbacks of Linq To Sql are, yet I believe the drawbacks are important to consider before adopting such a large disruptive change into a software development environment.

Here are some of the downsides to LinqToSql that I have identified so far:

  • There is a significant learning curve.  The technology is deceptively approachable.  On the surface, for instance, LinqToSql takes a SQL Server database table and generates .NET source code for a .NET CLR class.  This appears to be a nice abstraction.  However, there is a significant amount of complexity involved.  The abstraction leaks.  Something doesn't work as you expect, so you start searching and reading and the reading seems to go on a lot longer than expected.  We are still early enough in the adoption cycle that many common issues and questions are under documented.
  • There is immature documentation.  As technologies mature, the documentation improves.  This is especially true of the documentation of more obscure issues available through things like google searches.  Right now, there are "gotchas" that remain hard to find clear discussion around.
  • There is a requirement for "seasoned" developers on the team.  The development team needs one or more developers who can learn new things quickly, handle significant amounts of complexity, and do the right thing without micromanagement.  These developers likely need significant SQL Server, ADO.NET, and object relational mapping expertise.  There is a limited quantity of these seasoned developers to go around.
  • There is significant competition.  There are a lot of players in the object relational mapping (ORM) world.  LinqToSql, other than being included free in Visual Studio, arguably doesn't add enough value (yet) to the space.  Many of the highest traffic parts of LinqToSql can be (and have been extensively) emulated with ADO.NET.
  • There is a significant amount of FUD and confusion around the future roadmap (i.e. version 2 and beyond) for Linq To Sql.  Microsoft is actively de-emphasizing Linq To Sql while maintaining that they will continue to support it for the foreseeable future.  While the Entity Framework may some day be a clear and straight-forward migration path for current Linq To Sql users, that is not the case today and Microsoft is having trouble with damage control around their confusing and mixed messages.  I wish I could link to something worth reading on this topic, but as I've said, Microsoft has really botched the communication on this issue.
  • There are significant bugs.  That is a normal course of business with anything that is basically on version 1 (and since VS 2008 SP1 has been released, LinqToSql could possibly be called version 2).  Here's an example of a bug that is likely to hit a decent portion of the LinqToSql user base.
  • There are significant tooling issues.  The O/R Designer and SQLMetal tools that come with VS 2008 are fairly blunt objects with fairly significant limitations.  While some commercial products have stepped in to fill some of the gaps, there are very limited free options available.  I hope to write a future blog entry with more details on the limitations in the VS 2008 LinqToSql tools (for one, see Do not use the Visual Studio 2008 LinqToSql O/R Designer).

LinqToSql will appeal to many people for many reasons and I think its momentum is likely unstoppable.

As with adopting any new technology, it's important to go in with your eyes open. 

Your mileage may vary.

Update 2009/09/16 - Here is a somewhat related follow-up blog post discussing where Linq2Sql matches up against other .NET ORMs: .NET and ORM - Decisions, decisions

Friday, May 29, 2009 12:22:38 PM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |  Comments [3]  | 
# Saturday, May 09, 2009

Here's a fairly nasty error message with a (sometimes) pretty subtle solution.  Let's say you want to insert a null value into a nullable database column with ADO.NET using parameterized SQL.  The insert statement could look something like this:

INSERT INTO TableName (ColumnName) VALUES (@NullableValue)

Let's say I setup my SqlParameter array as follows:

SqlParameter[] sqlParameterArray = new SqlParameter[1];
SqlParameter oneSqlParameter = new SqlParameter("@NullableValue", SqlDbType.Int);
oneSqlParameter.Value = null; // I want to insert the value null

If I ran the insert using the SqlCommand.ExecuteNonQuery method, I would get this exception:

--
System.Data.SqlClient.SqlException

Prepared statement '(@NullableValue int)INSERT INTO TableName (ColumnName) VALUES (@' expects parameter @NullableValue, which was not supplied.
--

What's wrong?  Apparently, "null" is not a valid value for the Value of a SqlParameter.  You need to do this instead:

oneSqlParameter.Value = DBNull.Value;

Is that error message helpful?  I don't think so.

There are plenty of other reasons why that exception could be thrown, but I've been using ADO.NET for a while and I still stumbled upon this particular under documented problem recently.  Very, very subtle.  Crystal clear error messages from software are so important, yet so uncommon in the real world.

Saturday, May 09, 2009 12:44:29 PM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
# Sunday, May 03, 2009

More and more software products are including a feature that allows using the Lua programming language to author addons that add additional features to the base software product.

One of the most notable of those products is World of Warcraft.

World of Warcraft players can write Lua addons to modify and enhance the user interface in many useful ways.

As a player of World of Warcraft for three years, I've enjoyed using many of these addons and even started to create my own.

The addon I developed seemed useful enough that I thought other players may be willing to purchase the addon for real money, even though the large majority of World of Warcraft addons at the time were free.

Long story short, the company that created World of Warcraft turned on their addon developers and effectively outlawed addon developers from making a living from addon development.

In the process of trying to commercialize my lua addon, I wrote a code obfuscator for lua.  That obfuscator doesn't have much use to me at the moment, so I put a web front end on it and I'm publishing it to see if other people can get any meaningful use out of it.

This version (v1.0.0.4) is free to use with limitations on how many text characters can be processed per day and per IP Address.

Click here to: Obfuscate Lua

There is a feedback page as part of the lua obfuscator application that allows you to submit feedback of any kind.  Please let me know what you think!

Sunday, May 03, 2009 2:20:31 PM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  |