I’ve been a fan of Mindscape’s LightSpeed ORM for a while.  I think that it’s a great alternative to LINQ to SQL (L2S) and NHibernate (NHib).  I work in a shop where we use both NHibernate and L2S very heavily and I have great respect for both of these products, but I’d really like to attempt some real work projects with LightSpeed.  Up to this point, I’ve used it to put together my own prototypes, which typically get moved to a different technology when I apply these technologies in the work environment.  I plan on following up with some articles actually using LightSpeed in a “personal application” I’ve been thinking about for a while, but I also wanted to make an attempt at defending such an ORM for commercial use.  It’s a pretty hard argument in many shops, based on how entrenched NHib and L2S have become, but I’d like to attempt to make a case to the contrary.  I think the most obvious reason that it’s hard to justify a commercial ORM is pretty valid:

L2S and NHib are both free, why would I want to pay for an ORM?

I think this is a great question.  You definitely get a lot for free with NHibernate and L2S.  I would boil the answer down to a simple question:  What is the true cost of ownership and ROI when you factor in developer productivity.  Consider the cost of LightSpeed.  I believe that they are changing the licensing a little with 3.0, but I think it’s going to be something on the order of $149-199 per developer according to the guys at Mindscape.  Let's say this adds up to 3-4 man hours.  So the question is, does the LightSpeed provide productivity enhancements that would save this 3-4 hours per developer over the course of a project.  Not to mention that it could be used across several projects, I think the answer is an absolute yes.  I’m basing this projection based on two factors:  features and support.  If you feel that I’m shortchanging either NHib or L2S with any of these comments, please feel free to set me straight.

Features

NHib is very feature rich, has a lot of third party add-ons, and it’s probably the most flexible ORM as far as scenarios that it will support.  For example, it supports some inheritance approaches (table per subclass for example) that LightSpeed doesn’t support.  So there are some scenarios where NHib is the obvious choice.  For example, if you are plugging into a legacy app, NHib may support some scenarios that are necessary for you.  But to be honest, LightSpeed will support a surprising number of setups (especially with some of the 3.0 improvements, such as support for compound keys) and as a green-field tool, it’s hard to beat.  There are also some great features that LightSpeed 3.0 has right out of the box that NHib doesn’t have, or that you have to track down as a third party tool.  On the other end of the spectrum, there is no doubt that L2S is a great RAD tool, but when it comes to enterprise features, it is pretty weak in some key areas.  I think LightSpeed finds a great middle ground with awesome RAD features, but at the same time, great support for some necessary enterprise functionality.  Here is a list of things that I just think are easier with LightSpeed or just plain don’t exist in L2S or NHib.

1. Multiple Database Support - OK, NHib supports a lot of databases, and we know L2S is SQL Server specific.  Like NHib, LightSpeed supports a ton of databases, my guess is that it supports some that even NHib doesn’t cover, such as limited support for Amazon SimpleDB.
2. LINQ – OK, obviously L2S has great LINQ support.  While I know NHib has LINQ support, it’s not very thorough, and to be honest, I don’t know of many people that are comfortable leveraging it in production environments.  Steve Strong has been working on a more comprehensive LINQ provider and I’ve been following him with keen interest, but this is no small task for any developer.  LightSpeed has supported basic LINQ functionality for quite a while, and with LightSpeed 3.0, the LINQ support is greatly expanded.  I have a fair amount of confidence in the guys at Mindscape because this isn’t new ground for them, they’ve been doing LINQ for a while.
3. Visual Designer Support – In contrast to NHib, LightSpeed works well as a true RAD tool.  Want to throw together a quick prototype, quick and done with LightSpeed.  Straight up, I love the LightSpeed designer.  And I completely reject the idea that “real developers” don’t use designers.  Real developers use the tools at their disposal to deliver solutions in the most efficient, maintainable, communicable, and cost-efficient manner possible.  Their designer is just plain done well.  It’s simple, provides a visual representation of the model (which is invaluable when discussing entity relationships), and supports additional features such as model filtering, inheritance visualization, name refactoring, and too many others to mention.  Short story is that NHib doesn’t have a decent designer, and while L2S has one, it’s extremely limited.  I know you can use Sculpture with NHib, but you’re getting into a quasi-commercial tool at that point.  OK, so you don’t like designers?  Well you don’t have to use the designer with LightSpeed if you just can’t bring yourself to use it: It’s got command line tools as well and you can even provide your own custom code generation templates.
4. DB Schema Synchronization - LightSpeed has a simple helper built in for forward and reverse engineering from the database, which will let you select the individual items to synchronize and give you an option to spit out the scripts or just apply them.  Sweet!  Yes, I know NHib has support for forward engineering from the model, but the difference is that LightSpeed makes it so darned easy.  Just a couple of clicks on the designer and you’re done.  Synchronization with L2S typically has me pulling my hair out.  Sometimes it’s just easier to delete the Entity from the L2S designer and re-drop it.  Hope you didn’t make any changes!
5. Migrations - Migrate the database schema from one version of your app to the next.  This is new with 3.0.  I’m hoping this will really help me cut down on the DB scripts that I write.  There are some great third-party tools that can accomplish this, such as Tarantino, but now you are launching into a whole new product and learning curve.  Having a migration tool built into LightSpeed is just plain nice.  One stop shopping in short.
6. Validation Framework – LightSpeed has a great built-in validation framework that supports declarative attributes.  Sure there is Castle and Enterprise Library, but again, one-stop shop.
7. Level 2 Caching Support – NHib has great level 2 caching support, but this is sorely lacking in L2S.  You can implement your own, but LightSpeed has a couple of options, including the standard web cache as well as support for Memcached right out of the box.  You just state that an item will be cached right in the designer.
8. Little Time-Savers – LightSpeed has some nice little “convention” productivity features that save you time, such as automatic setting of created and updated dates, soft delete, and concurrency handling if you just add the correct fields to your table for the entity.  In addition, it has built in change tracking with LightSpeed 3.0 if you need it for auditing purposes.
9. Random Things You Need for Enterprise Apps – A few other things that are problematic for L2S, but that LightSpeed handles out of the box:  Many-to-many, flexible eager loading, efficient query batching.

Support

A major lacking factor in both L2S and NHib is support.  This is an unbelievable differentiator when you consider ROI.  Sure you can buy support for NHib, but then it wouldn’t be free anymore, would it?  And good luck getting anything related to L2S fixed at all, much less in a reasonable timeframe.  There is a lot of literature published on both of L2S and NHib, but I have spent countless hours accumulating enough knowledge on both of these products to become relatively proficient.  And still sometimes, I’m combing the web, hunting for answers for quite some time.

In contrast, I’ve always gotten amazing support from the Mindscape guys when I had a question about their product.  This is considering that I’m a measly 1 license holder, and not even their enterprise license.  In fact, Mindscape was extremely responsive before I had purchased anything from them, I was just using their free version for a while.  If you find an issue, chances are that it will be corrected in the next nightly release.  If you have a compelling suggestion, chances are that your suggestion will also be included in a nightly release.  I had just such a case when I suggested that they add GUID.Comb as an identity strategy.  A couple of days later, it was implemented and available in a nightly build. 

How about the response:  NHibernate is open source; if there is something I want to implement, I can do it myself!  More power to you, but honestly, I’ve got deadlines and a set number of billable hours on most projects, and while I use NHib a lot, I’m not really interested in becoming an expert on it’s inner workings.  Isn’t it great to have a team dedicated to helping you with these issues instead of having to address them yourself?  For the sum they are asking…no question.

My Biggest Issue

My  biggest gripe with LightSpeed is that it relies on inheritance.  So you end up polluting your model a bit with a LightSpeed reference and base class, and if you use LightSpeed in the most common manner, the classes will be generated on your behalf by the designer and code generator.  When you are going with an “Onion Architecture” approach, which is what I try to do in general, this can make you feel like you are sinning a bit.  However, LightSpeed does a few things to mitigate their interference, which I’ve decided I can live with given everything LightSpeed does for me:

1. All generated classes are partial, making them easy to extend.
2. You can insert your own base class(es) into the class hierarchy.  So in my case, I have a BaseEntity class that contains some core entity commonalities.  I want to use this as the basis for most of my model entities.  I can inherit my BaseEntity from the provided LightSpeed Entity class and tell LightSpeed to substitute it as the basis for one or more of the model classes generated by the designer.
3. You can import any of your custom types into the designer.  If you want to reference your own type, such as an enumeration in place of an Int32, it’s very easy to pull the type into the designer and tell LightSpeed to map to your custom type.
4. With LightSpeed 3.0, the generated classes give you a number of productivity features that I would have to implement anyway, such as change tracking and the other features mentioned previously. 

So I’m ceding some tight coupling to the ORM.  And frankly, if I decide I’m going to Production with an ORM technology, I’m not going to rip it out and replace it for a while.  So I accept that I am going to pay a price if I decide to change course on the ORM.  I think this is a given with any of the ORM technologies though.  Think about all of the HQL queries to refactor if you decide to drop NHib, all the mappings to update, etc….  I recently upgraded a project from NHib 1.2 to 2.x, and although it wasn’t too bad, even this was far from frictionless.

As mentioned above, I plan to follow with a few articles using LightSpeed 3.0 in an actual application, highlighting some of the features I’ve mentioned in this article.  Looking forward to any comments you may have.