Mindscape LightSpeed an O/R Mapper Done Right

Anyone who reads this blog knows I work with quite a bit of different technologies, some I love and some I just tolerate.  One of the technologies I love is Ruby on Rails, for many different reasons, but one huge reason is the way it allows the developer to interface with a database.   When I create a Ruby on Rails application with even a single migration, I have access to my database tables as objects in my application with very little work.

Now transition to the life of a .NET developer.  Someone given the task of creating a database application with the job of simply adding, updating and deleting records from a database is faced with many choices with very few offering the elegance of a tool like Ruby on Rails.

I was hired recently to create a new web application which required it to be written in ASPNET with C#.  This gave me the opportunity to look at all the key aspects of the application and the first to get stuck in my mind was data access.  Which tool to use on .NET?

I write both Ruby on Rails and ASP.NET applications and transitioning between the two is often difficult when faced with the plethora of ways to access data in .NET, most seem to be more complicated than necessary. 

Microsoft Data Access

Technologies created by Microsoft only seem to make it to market if they are complicated and cumbersome to use, these include:

ADO.NET – Using stored procedures for example.

LINQ to SQL – In my opinion, a real clumsy attempt to give a way to access almost anything by a query language implemented in C# or VB.NET.  You can see by example that no one should have to write these things all day:

var q =
   from c in db.Customers
   where c.City == "London"
   select c;
foreach (Customer c in q)
   Console.WriteLine(c.CompanyName);

Entity Framework – Oh please.  I have only given this technology a cursory look and just have to shake my head in disbelief that Microsoft would create such a mess of complexity, but they do complexity best.

Non-Microsoft Data Access

There is hope though for developers wanting something better.  Technologies like SubSonic and NHibernate offer very different solutions to Microsoft’s vision of how data access should be done.  Both of these are open source projects and have their strengths and weaknesses, and both have their own learning curve.  I have spent some time with SubSonic and it is good product with active development.  I can’t say I have done very much beyond the experimentation stage with NHibernate but I know many folks who love it.

I had been a bit oblivious to work being done with data access and object relational mapping (ORM) in the .NET space.  I came across one tool from Mindscape, a New Zealand based company, with an ORM tool called LightSpeed.  I was a little reluctant because of my assumed learning curve and could not have been more wrong.  This is a commercial product but Mindscape offers a free version that is full-powered but only allows for up to 8 database tables, which would be fine for smaller projects or to try it out.

After speaking with some other developers who have been using LightSpeed I decided it was the right tool for the job.

LightSpeed in Action

The project I had in mind was indeed a new project but I inherited an existing SQL Server 2005 database full of tables.  This application will consume many of the existing tables read-only but we create new tables to store our application-specific data.

This is not a tutorial on how to use LightSpeed but how I am using the tool.  I am sure there are many ways to configure the tool to use the data most efficiently.  I am sure the purists will complain about doing model-driven design, but I don’t care.   I was looking for a tool to get up and running with the least effort, we will tweak later.

LightSpeed comes with a really nice designer which allowed me to pick and choose various tables I wanted to use in my application.  Notice how the designer picks up the existing relationships from the database:

LightSpeedDiagram

Once the designer is saved it quickly creates some very clean C# to represent the schema in code.   A few entries in the web.config and everything is ready to write some code.  Mindscape has a nice Getting Started screencast which shows how easy it is to go from zero to code.  The screencast is just over 11 minutes long and is enough to get up and running.  

Setup Code

A bit of setup code in my application gives us access to our database and a place for our objects to interact with:

        private LightSpeedContext<UnitOfWork> _context;

 

        public LightSpeedContext<UnitOfWork> Context

        {

            get

            {

                if (_context == null)

                {

                    _context = new LightSpeedContext<UnitOfWork>

                                   {

                                       ConnectionString =

                                           "Data Source=.;Initial Catalog=terminal_link;User Id=dbuser;Password=xxxx;",

                                       PluralizeTableNames = LightSpeedContext.Default.PluralizeTableNames,

                                       IdentityMethod = LightSpeedContext.Default.IdentityMethod

                                   };

                }

 

                return _context;

            }

        }

 

Once we have a Context property setup this will be the basis for all database access.  Notice it is created only once.

Retrieving Entities

All the code is very simple but does a lot.  We need an entity here for a certain ID and we are using the LightSpeed method of query, you could just as easily use LINQ queries.  I choose to stay away from them and use the cleaner method of retrieving an entity object.

        public TltForeman GetForemanByWorkId(string workId)

        {

            using (UnitOfWork uow = Context.CreateUnitOfWork())

            {

                return uow.FindOne<TltForeman>(Entity.Attribute("ForemanId") == workId);

            }

        }

Creating Entities

Passing in an instance of our entity, adding to what is referred to as a UnitOfWork and just calling SaveChanges does the job.

        public void AddForeman(TltForeman foreman)

        {

            using (UnitOfWork uow = Context.CreateUnitOfWork())

            {

                uow.Add(foreman);

                uow.SaveChanges();

            }

        }

Deleting Entities

Deleting is as simple as adding, pass an instance of our entity and remove from the UnitOfWork and SaveChanges and the entity is gone.

        public void DeleteForeman(TltForeman foreman)

        {

            using (UnitOfWork uow = Context.CreateUnitOfWork())

            {

                uow.Remove(foreman);

                uow.SaveChanges();

            }

        }

Finally

This tool is really a pleasure to use.  I don’t know if I am partial to it because of my work with Ruby on Rails or just the beautiful simplicity, but it is worth a look.   Don’t get me wrong, it does not lack features but its features don’t get in your way.  I can tweak all I want, something the Rails community refers to as convention over configuration.

The amount of time to go from database to working application was cut probably almost in half.  No stored procedures were created in the making of this application.  This fact alone should be a good enough reason to move from traditional designs to using an ORM to avoid stored procedures and save some time.

Why should managing data from an application in .NET need to be such a task, which is one we repeat over and over.  Using LightSpeed has eased the pain to get an application done rapidly and is a welcomed tool to my toolbox when I need to get .NET work done.

 

 

Feedback

 avatar
#1
Jayme Davis
11.23.2009 @ 12:48 PM

Killer post, Rob!!

rbazinet avatar
#2
Rob Bazinet
11.23.2009 @ 1:26 PM

@Jayme - Thanks, it was your input that led me to use it. I can't say enough good things about it really. Microsoft needs to take a lesson on how to really create a data access tool.

 avatar
#3
Todd
11.23.2009 @ 1:35 PM

Hi Rob,

I follow you on Twitter and this is the reason why. We often have the same philosophy on web dev and this is one product I have been eying for a while. I currently use EntitySpaces but think this is worth a demo and seeing for myself how it can help me....and also trying RoR one of these days.

Todd

rbazinet avatar
#4
Rob Bazinet
11.23.2009 @ 2:28 PM

@Todd - thank you for the kind words. I have heard of EntitySpaces but never tried the tool. I may have to give it a look. I like to find tools that make my job easier and more pleasurable rather than more painful. MS too often gives us tools that are used to whack ourselves in the head.

 avatar
#5
Citizen Luca
11.24.2009 @ 1:45 PM

Excelent post, Rob!!

 avatar
#6
David
11.24.2009 @ 3:42 PM

Re: "You can see by example that no one should have to write these things all day"

var q =

from c in db.Customers

where c.City == "London"

select c;

Maybe I'm being thick, but I'm not seeing why this code is obviously so horrible?

 avatar
#7
Sergio
11.25.2009 @ 8:01 AM

if you think

return uow.FindOne<TltForeman>(Entity.Attribute("ForemanId") == workId);

is easier to understand than the LINQ to SQL / EF equivalent

return _context.Foremen.SingleOrDefault(f => f.ForemanID == workId)

then i really need to be enlightened. Your query also has the small disadvantage that you're supplying the ForemanId as a string, so you get no intellisense, and can make you waste a lot of time to find out that you wrote "ForemenId" instead of "ForemanID".

Not that EF is the non-plus-ultra, it has a lot of quirks and problems, but i think it is moving in the right direction. EF4 is definitely full of very useful features (Code Only, better Unit Test support, Model First, etc.).

rbazinet avatar
#8
Rob Bazinet
11.25.2009 @ 10:26 AM

@David and @Sergio - I expressed in the post MY preference and what I think is a more understandable, readable and maintainable syntax. I certainly can't argue, and won't, about the preferences YOU have. I respect folks that stand up for their preference, certainly LINQ to SQL is used by many and EF4 has a lot of new features but for my preferences I like to just get thinks up and running and tweak later.

Thanks for the comments.

 avatar
#9
mike
11.25.2009 @ 12:33 PM

Well I have been using lightspeed on a project for approx 8 months now and while I can agree with most of what you say and do quite like lightspeed compared to other tools, it definitely has it's problems. Change tracking being a big one if you do a lot of updates... and linq selects that load the entire table into memory when there is no need... I have had significant performance issues once record counts get beyond a couple thousand and have had to move large portions of the app into stored procs for performance. Their designer is awesome though and V3 looks like it will solve some of these issues and they are really very responsive to bugs and a great company. Honestly since I use sql server for all my database work, linq2sql would have probably have been a better choice knowing what I know now. EF1 was unusable, but EF4 looks very, very attractive.

 avatar
#10
wekempf
11.25.2009 @ 12:38 PM

"I respect folks that stand up for their preference, certainly LINQ to SQL is used by many and EF4 has a lot of new features but for my preferences I like to just get thinks up and running and tweak later."

But that's where your article fails, miserably. EF4 has THE EXACT SAME WORKFLOW you used in this post. Design the model in a designer, generate code from that, use the code. Using the code is even nearly identical, excepting some minor syntactic differences (where LINQ is better, because it doesn't employ magic strings). So, while I won't argue with you about YOUR preferences, I will point out that you spent an entire article blasting Microsoft for producing frameworks that are too complex, and then failed miserably to illustrate how LightSpeed is any less complex. It appears you were prejudiced and didn't even look at LINQ to SQL or EF4, beyond evidently not linking the LINQ syntax.

rbazinet avatar
#11
Rob Bazinet
11.25.2009 @ 12:48 PM

@mike - I have heard about a few limitations with LightSpeed 2 as well but have not hit any myself, just yet. I also heard v3 will fix these issues and ease some of the pain folks have experienced.

My feeling is LightSpeed fits a nice niche for those just wanting to get work done. EF4 is powerful, no doubt, but not for a small company running agile. MS is targeting enterprises and that's fine but the tooling reflects that much of the time, so I appreciate tools like LightSpeed for leaving those tools in the dust.

rbazinet avatar
#12
Rob Bazinet
11.25.2009 @ 12:56 PM

@wekempf - LOL, did I strike a nerve? Thanks for the feedback but your comment fails from the point of not understanding how a tool like LightSpeed works. It's opinionated, meaning I don't have to fret the details, just use it and it works. EF4 is like a big, clunky machine I need to know too much about to use well but LightSpeed is fine tuned and runs out of the box just the way I need it.

I agree L2S is used by many, pretty much because they live or die by MS. They have become married to L2S syntax and live with it. It is damn ugly, IMO, so I choose not to use it.

Sure, the workflow is the same but the use of LightSpeed gives me less headaches to implement, period. I looked at both EF4 and L2S, which I have used for a while now and simply come to the same conclusion every time...WTF. I think the examples I gave pretty clearly show how LightSpeed is less complex, look at the code. How can I explain it any clearer to you? I guess if you are used to MS then maybe you think there is something hiding behind the scenes to make it all work, well there isn't. So, look at the simple example, it is well..simple.

I guess I am blasting MS, for creating clumsy data access tools. I don't see why the defensive tone, uh..did you have a hand in EF4? I certainly hope not.

 avatar
#13
wekempf
11.25.2009 @ 1:29 PM

Strike a nerve? Sort of. I despise religious debates in technical discussions, and you're obviously on one of those.

"It's opinionated, meaning I don't have to fret the details, just use it and it works."

Then make that argument. This post doesn't. Nothing in this post shows LightSpeed to be an opinionated framework, nor any different from any other ORM, much less EF4/LINQ to SQL. I'm not claiming there aren't differences, or valid technical reasons to prefer LightSpeed. I'm only claiming that you've not shown any.

"I agree L2S is used by many, pretty much because they live or die by MS. They have become married to L2S syntax and live with it. It is damn ugly, IMO, so I choose not to use it."

And there's the religion. The only reason people use L2S is because "they live or die by MS". Uh huh. And the damn ugly syntax is not backed up by anything other than "it's my opinion", which is non-helpful to anyone, especially when it's shown that the syntaxes are really extremely similar and the LINQ syntax has *technical* benefits.

"Sure, the workflow is the same but the use of LightSpeed gives me less headaches to implement, period."

Such as? You speak a lot of hyperbole, but give no examples.

"I think the examples I gave pretty clearly show how LightSpeed is less complex, look at the code."

I did. The equivalent in EF4 is nearly identical, as one would expect from such simple code examples. I'd expect pretty much every ORM to have extremely similar code.

"I guess if you are used to MS then maybe you think there is something hiding behind the scenes to make it all work, well there isn't."

No, I'm used to programming. I use many languages and technologies from many sources, both closed and open. I'm not claiming the Microsoft technologies to be better than LightSpeed. I can't, because I've never used LightSpeed. But I can claim that you've utterly failed to show how LightSpeed is any different, much less better, from EF4 or LINQ to SQL. If you think LightSpeed is better, than I suggest you try to illustrate why again, because you failed completely here.

 avatar
#14
Alex
11.25.2009 @ 1:33 PM

I have been using Lighspeed for about 6 months now and I love it. However, you should really look into using stringly-typed contexts. That will give you intellisense and compile-time error checking.

Then, you can say "Foreman.id" Much cleaner.

rbazinet avatar
#15
Rob Bazinet
11.25.2009 @ 1:38 PM

@wekempf - I despise religious debates to but you seem to want one and I will end it right here. I don't gain anything by you liking or disliking LightSpeed, so I don't care. I posted pointing out how, in my opinion, LightSpeed was an O/RM done right. You may choose to think otherwise, that is your opinion and I very much respect that view point.

So, not to continue an argument that has no real value here since my mind won't be changed, the point of my post was..I don't like Microsoft's solutions and I have found something I do like, so go check it out. I don't lay claim to being an O/RM expert and never will but I write software for clients who just want results. LightSpeed give me the ability to create results in a shorter timeframe than the others tools I have looked it.

rbazinet avatar
#16
Rob Bazinet
11.25.2009 @ 1:40 PM

@Alex- Thanks for the advice, I will take a look at strongly typed contexts. I have not dug any deeper that I have had to yet. This tool just works so nicely with the defaults I have that I am just thrilled. I know I will need to tweak some things, refactor others and I will look at your suggestion.

 avatar
#17
wekempf
11.25.2009 @ 1:48 PM

Man, Rob, you just don't get it. I'm not looking for a religous debate. I'm looking to learn something, and I can't from this post. You're now repeating yourself over and over again about it just being your opinion. Fine. Why waste an entire article doing nothing but stating an opinion? Back that opinion up with something, man! I want to know WHY you like LightSpeed better. Then I'll be able to form my own opinion about whether or not it's worth looking into LightSpeed. You don't do that here. Worse, you not only attack Microsoft, but you dismiss and berate commenters that point out that you've failed to illustrate any significant differences here.

rbazinet avatar
#18
Rob Bazinet
11.25.2009 @ 2:02 PM

@wekempf - First of all, I apologize if you think I am "berating" commenters, not my goal. I appreciate anyone that will take their time here to comment.

I wasted the entire posted stating my opinion because I can. :-) The point was, again, I found something cool, go check it out...or don't. My opinion is that I like it better than others, here is some code that shows the simplicity.

Honestly, I don't care enough about EF4 and L2S to spend the time to show those technologies vs. LightSpeed. What do I gain? If I was the developer of LightSpeed then I can say it is worth my time but is NOT worth it otherwise.

You have labeled me as "attacking Microsoft" pretty broadly. I just don't like EF4 and L2S, not sure how that qualifies really as attacking but to each his own.

 avatar
#19
John-Daniel Trask
11.25.2009 @ 5:01 PM

Mike,

Could you please get in touch with us about your issues with querying performance and loading all data into memory? That doesn't sound right at all - we've put huge effort into ensuring that our querying in LS is incredibly efficient.

Something sounds very wrong if you're seeing performance issues like that and I'd like to help you get to the bottom of them.

Appreciate your feedback about the things you like and those that you don't - it helps us continue improving the product for everyone :-)

Thanks,

John-Daniel Trask

Co-founder

Mindscape Limited

 avatar
#20
Sergio
11.26.2009 @ 5:53 AM

As wekempf pointed, your article sounds very biased by your particular preferences for Lightspeed and your particular dislike for LINQ. The simple steps you have described for creating an object model from your database, creating a context for it, and querying data from a single table, are just as simple in EF or L2S. The Syntax for retrieving a single record is also pretty much the same, only

- you don't need to use generics in LINQ, doesn matter much, but it's clearly not as easy to understand as NOT using generics.

- you don't need any references to an "Entity" Class and call the Attribute method to inform via a string parameter that you are querying for ForemanID. I am not sure how easy it would be to unit test your repository since it seems you have a strong dependency to Lightspeed.

In all, it's nice to see alternatives to EF and L2S that are relatively simple to setup, but i would not diss EF and L2S because of what seems to be personal bias only.

 avatar
#21
Joseph
12.08.2009 @ 12:31 AM

Thanks for the pop. Lightspeed's been a boon!

 avatar
#22
HARISH
12.22.2009 @ 12:54 AM

Microsoft needs to take a lesson on how to really create a data access tool...

 avatar
#23
guest
12.27.2009 @ 11:41 PM

Thanks for your detailed information on microsoft and non-microsoft accesses.The code you have given is very explanatory and easy to understand.I definitely go for it.

» Trackbacks & Pingbacks

  1. Pingback from Twitter Trackbacks for Mindscape LightSpeed an O/R Mapper Done Right : Accidental Technologist [accidentaltechnologist.com] on Topsy.com

Trackback link for this post:
http://accidentaltechnologist.com/trackback.ashx?id=437

Leave a Comment