Entity Framework vs. LightSpeed

Recently there was an article posted on InfoQ about the seven most requested features in the Entity Framework. We at Mindscape love the Entity Framework – it’s the best sales tool for LightSpeed that there could be! We decided to walk through the list and see how LightSpeed compares.

Improved SQL generation
EF Status: Planned, but only some improvements
LightSpeed: Already miles ahead, always improving

Now, to be fair, querying is really hard to get right and there are always cases that can always be improved. I’m sure every O/R Mapper out there has at least a few queries that they generate in a non-optimal way (yes, including LightSpeed) — but I think we can all agree than 5,000 line SQL queries from 5 lines of LINQ is a bit on the insane side.

Batch support
EF Status: Under review
LightSpeed: Since version 1 in 2007

LightSpeed is about being a full ORM but with as much speed as possible. We built in batching of inserts, updates and deletes from day one, not to mention batching on the select side to enable entire aggregates to be loaded in a single database access. LightSpeed automatically batches up CUD statements, reducing the number of database accesses for large updates by a factor of 10 or more.

By the way, LightSpeed also supports bulk updates and deletes, so if you have a raw database update that doesn’t need the business logic and domain-specific API of your entity mode, you don’t even need to load entities into memory to perform the update or delete them.

Support for a second level cache
EF Status: Under review
LightSpeed: Since version 1 in 2007, pluggable, ships with standard cache and memcached support

LightSpeed supports a first and second level cache and has always done so. A second level cache improves speed and reduces load when you have entities that rarely change (such as reference data), or when it’s not essential to have up-to-the-microsecond data. Caching is an essential element of a performance tuning strategy and we don’t think you should have to hack the underlying ADO.NET stack to get it.

Between inefficient selects, inefficient CUD and no second level caching, performance certainly is not a criteria that you’ll achieve with EF.

Support for multiple databases
EF Status: Under review
LightSpeed: Not planned

Would you believe we actually don’t support this either? Developers seem fairly keen to not want to touch their database for things like database spanning but it’s our view that this is not an ORM concern. If you need linked servers and other cool features like that then you should look at how the database engine can support this, not your mapper.

Note: Support for multiple databases as requested by EF users is for spanning databases not about database engine support. LightSpeed supports 9 different database engines out of the box.

Support for models with >200 entities
EF Status: Use several models (read: not planned or under review).
LightSpeed: Supported, and include multi-model file support.

When we released the LightSpeed Designer initially we were pleased with it – really nice looking, smart database diffing, etc. Then, Murphy’s Law: a user had a database with 2,000 tables! Not surprisingly, it was a tad slow working with that many entities on the design surface. We shipped a nightly build within 48 hours that made the designer lightning fast for this user and they never looked back. That was several years ago.

Of course, even eliminating performance concerns, working with that many entities can still be difficult. Computer screens are only so big, so it’s hard to visualise very large models. We’ve done a number of things to help with this, from entity colouring to pick out key entities or group related entities, to multi-file models, to navigation and filtering to locate the part of the model you need to work on and hide all the extraneous noise. You can even save the most common views and switch between them with just a couple of clicks. So we’re confident that even if you’re working with large models, the LightSpeed designer will still give you the best experience around.

Designer support for GUID keys
EF Status: Use a workaround of editing EDMX by hand. Changes to model mean you repeat the process again.
LightSpeed: Supported since day 1 with the LightSpeed Designer.

Seriously, how do you even miss this out? I guess if supporting enums seemed a bit hard than GUID keys must seem like crazy talk.

Schema Migration
EF Status: Currently in beta
LightSpeed: Added in 2009.

LightSpeed includes a powerful schema migration product. Including Visual Studio integration, server tools and the ability to switch database engine targets, you’ll struggle to find a better schema migrations framework for .NET. Read more about schema migrations that were included in 2009.

We’re constantly improving the cabilities of the migrations engine based on user feedback as well.

So why would you choose to use EF? Here’s a couple of common counter arguments for using EF:

“It’s Microsoft – it will get better!”
Sure it will, maybe in five years time. Unfortunately your software needs to be written today, not in five years. Microsoft also has a really bad history of killing data access technologies so I’d be more concerned that the improvement will be to throw out EF and start again. And honestly, how much better do you think it will be in five years time? The pace of improvement so far has been glacial, and of these seven most requested items, only two are being worked on currently.

“Entity Framework is free – LightSpeed isn’t!”
It’s true that our free edition of LightSpeed is only for small databases. If you think your solution doesn’t require good performance, nightly updates, a responsive support offering or solid foundations then by all means, lock in Entity Framework. We can guarantee you that you’ll waste more money fighting in the weaknesses with the Entity Framework than you would have ever spent getting a LightSpeed license. EF is only free if your time is worthless.

That’s a wrap

We’ve got a lot of friends in Redmond, and we think a bit of rivalry is good for everyone, as well as a bit of fun. And we know that there are a few popular feature requests for LightSpeed that have been outstanding for a while too! But we do feel quite seriously that it’s important for developers to make an informed choice about their tools. Because Entity Framework ships in Visual Studio, it’s easy for it to become a de facto choice, without considering the alternatives.

But if you like knowing that if you run into an issue you can get help directly from the developers then choose LightSpeed. If you like getting nightly builds with not just bug fixes but cool new features then choose LightSpeed. If you like your data access to be fast then choose LightSpeed. If you would like to use a more mature, more powerful and, frankly, more loved ORM then give it a go — grab the free version of LightSpeed and see what you think. We’d love to hear your feedback!

Tagged as LightSpeed

6 Responses to “Entity Framework vs. LightSpeed”

  • I made a comment on the 5000 line user voice site.

    Diego, No offense but moving to v4.5 of the framework is really not an option for the majority of corporate software. I have been using Lightspeed for over 4 years and it does not force me to upgrade the core runtime when improvements are made. http://www.mindscapehq.com/products/lightspeed

  • The SQL Generation stuff in EF cracks me up, LINQ allows you to write the most bizarre queries which work, but the generated SQL is a WTF. I blogged about one such case about someone trying to translate an EF query to NHibernate.

    http://www.philliphaydon.com/2011/08/nhibernate-work-around-is-not-really-a-work-around/

    MS should just buy LightSpeed.

  • Hi John,

    The purpose of the InfoQ article was not to bash Microsoft, it was to help existing EF users work-around the existing limitations until we see these features come out.

    Of course kudos to the Lightspeed team to have most of these features already.

    Just note that the work-arounds are not from Microsoft, they are from the community. This article makes it look like MS gives those work-arounds as excuses not to build the features which isn’t quite right.

  • Entity Framework is killing e-sports.

  • Agreed that EF is off in the weeds. Lack of Enum support is what drives me nuts. Four years and counting on that promised feature.

    I see you are not supporting “multiple databases.” What about SQL Federations? Additional SQL needs to be sent and it is based on key. Doing this efficiently with connections and cache requires an abstraction that does not yet exist in Lightspeed.

    Seems like something that belongs in an ORM, not that Microsoft has figured this out yet, either:

    http://windowsazurecat.com/2011/09/sql-azure-federations-entity-framework-code-first/

  • Guys, please, add to list one more item:
    “Support Visual Studio 11 Preview” with LightSpeed marked “Yes”!!!

  • Leave a Reply

Archives

Join our mailer

You should join our newsletter! Sent monthly:

Back to Top