Home » Blog

Archive for the ‘LightSpeed’ category

Nightly news, 9 December 2011

The big news this week is the release of WPF Elements 5.0. We’ll have a post up in a moment to let you know what’s new and what’s hot, so stand by to give it a go!

Of course, even with our heads down on WPF Elements 5.0, we’ve still got updates to our other products. Here’s what’s new in this week’s nightly builds.

LightSpeed

• Fix for joining of class table inheritance base class in certain eager load queries
• Fix for issue with descending order in a wrapped distinct query for databases that use ROW_NUMBER-style paging
• Fixes for migrations spuriously trying to recreate auto through entities and one-to-one associations which had not changed

Usual rules apply: free editions available from the downloads page, full editions from the store.

5 reasons not to use a micro ORM

If you haven’t come across the concept of a “micro-ORM,” it refers to a currently fashionable category of data mapping tools which take a minimalist approach to mapping between the database and object worlds. Typically the focus is on materializing a data reader row to a class. That’s the key functionality although features do vary. A developer would typically write inline SQL for the query they wish to run. They are fairly simple, and that’s their point — to not have the weight of a fuller featured ORM.

We do get asked by people who have started to hear about micro-ORMs: when would I choose a product like LightSpeed over a micro-ORM? Both address the same basic job of mapping between SQL data and in-memory objects, so why use one rather than the other? So here are some of the times we think you’d want to use a fully fledged object-relational mapper.

1. You’re not Stack Overflow

Stack Overflow has become the ‘go to’ reference site for micro-ORMs. I mean, if Stack Overflow built a micro-ORM to squeeze out the performance they needed, that means they’ve got to be good, right? But I’ll let you in on a secret: you’re not Stack Overflow.

Stack Overflow is a huge site under extremely heavy load. That makes their performance tradeoffs entirely different from most sites or applications. Most developers, as long as they’re not introducing any performance killers, should be focusing on productivity, not on micro-optimising performance. Rather than handwriting SQL and forgoing additional benefits like validation, integrated migrations and many more nice-to-have features to gain the benefits of needing a smaller server farm, most companies find developer productivity is where they can save more money.

2. You’re not building a throwaway app

Some folks feel that it’s quicker to get up and running with a micro-ORM than with a full ORM. And if it’s quicker to get up and running, that means the micro-ORM is more productive than the full ORM, right?

Well, maybe. Some ORMs do require quite a bit of configuration or repetitive mapping. We’d like to think that LightSpeed isn’t one of those. We reckon that with LightSpeed you can be up and running in less than a minute. Plus you can actually gain time by having LightSpeed create the database schema for you, rather than having to jump across into a database tool.

But fair enough, it does take longer to install LightSpeed than to pull down a micro-ORM via NuGet. So if you’re only going to be spending ten or fifteen minutes on your application, then that might be decisive. But for most realistic applications, the productivity benefits of a full ORM rapidly overtake the time savings of running an installer.

3. You want a domain model

A lot of micro-ORMs are just a class for materializing a database row into an object – either to a concrete class, or to an anonymous type. ORMs like LightSpeed, NHibernate, LLBLGen etc offer far more than just object materialization. If you want to express business logic, have validation, etc. then you either want a higher-end ORM or you want to spend your time writing a lot of tedious boiler plate code. And you probably have better things to do with your time than write tedious boilerplate code.

A domain model also pays off when you’re not the only one working on the project. Encapsulating business logic and validation in the domain model ensures that the business rules apply wherever the objects are used — you’re not relying on everyone remembering to apply the latest rules to their bits of the project. That’s one of the reasons we stopped using DataTables in the first place, remember?

4. You like LINQ

Most micro-ORMs do not include a LINQ provider. Most in fact require that you write the SQL yourself. That isn’t in itself a bad thing, it’s just taste and portability concerns and, frankly, most people don’t move database engine anyway. However, a LOT of .NET developers like LINQ. Many, many more than like SQL. Intellisense, compile-time type checking and compile-time syntax checking combine to make you more productive and to catch errors earlier.

And if you like LINQ, then you’ll want an ORM with a good LINQ provider. That means the LINQ actually translates to SQL, not a supposed LINQ provider that actually pulls all of your data into memory and then uses LINQ to Objects — that will throw away any performance gains you thought you’d be getting from the micro-ORM — and then some.

5. Your data usage pattern isn’t dominated by isolated records

There’s some great performance benchmarks out there for micro-ORMs. Unfortunately, there are a bunch of, well, less great ones too — benchmarks that don’t test real world situations.

If you’re going to be guided by benchmarks, make sure that the benchmark you’re using reflects how your application uses data. For example, suppose your application issues multiple queries to the database, some of which could result in the same entity being returned. Most micro-ORMs don’t use an identity map, so they’ll trundle off to the database and materialise a new copy of the entity. Most full ORMs, by contrast, will see that the entity is already in memory, and save themselves the query and/or the materialisation. And, by the way, they’ll give you handy object identity behaviour instead of you having to write code to test if Instance A represents the same record as Instance B. A typical full ORM is built to have a higher level view of how real world applications are built, and can gain significantly on the performance front by performing these optimizations.

Of course, your application may have special performance characteristics that mean a micro-ORM plus custom performance strategies will perform better than a general-purpose ORM tuned for a typical mix of applications. Stack Overflow is a great example — its performance requirements are so extreme that it’s worth the effort of building that stuff in a way that works for them. You have to ask yourself whether your application justifies that custom construction cost.

And one reason *to* use a micro-ORM

Choosing between a micro-ORM and a higher end ORM shouldn’t be a religious decision. There are certainly places where a micro-ORM makes sense — when you don’t need domain logic, you want to work very intimately with the database, the application is very limited or ad hoc in its scope… an example might be a simple bulk data transfer application, where things like an identity map and validation don’t add any value. We use micro-ORMs at Mindscape when they make sense, and it’s given us an appreciation of their value as well as where they come up short.

So what do you reckon? Are these the key points to consider when deciding between a full and a micro-ORM? What are your reasons for using or not using a micro-ORM?

Nightly news, 2 December 2011

We’ve said it before and hopefully we won’t have to say it again — we’ve been heads down this week putting the final polish on WPF Elements 5. That hasn’t stopped us making some nice improvements to Web Workbench and a few fixes to the rest of our products. Here’s what’s new in the latest builds.

LightSpeed

• Fix for error when doing a uniqueness validation on a field of a value object
• Fix for issue with joined queries on soft-deleted entities
• Fix for autocompiled FindById queries on SQLite with GUID identities
• Fixed an issue where certain types of LINQ queries could be rejected even though they were actually translatable

WPF Elements

• Fix for using the Esc key to cancel a zoom in progress on a chart

Web Workbench

• Fix for highlighting errors with Sass interpolated variables
• Fix for highlighting errors with nested multipart selectors consisting of a parent-pseudoclass followed by a subselector. Yes, you heard me
• Several intellisense fixes and enhancements

All these updates are in the latest nightly builds. Free editions available from the downloads page, full editions from the store. Web Workbench updates through Visual Studio Extension Manager.

Nightly news, 25 November 2011

This week we have mostly been flinging sheep at each other in a bout of pre-election excitement, but we’ve also shipped a good batch of updates. Here’s what’s in the this week’s nightly builds.

WPF Elements

• Fix for chart update when an alternate axis is zoomed programmatically
• Fixed automatic bar chart LabelLayout option
• Added DataSeries.LabelBinding property for conveniently setting data label content

LightSpeed

• You can now skip initialising entity collections that you’ll never need.

Web Workbench

• Updated Less compiler to 1.1.5
• Updated CoffeeScript compiler to 1.1.3
• Fixed a possible race condition
• Fix for Sass user-defined function causing highlighting errors
• Added highlighting for @font-face directive in Sass @mixin declaration
• Fix for top-level Sass @includes

NHibernate Designer

• Added public get/protected set visibility option
• Added policy option for visibility of default identity properties

Nightly builds of WPF Elements and LightSpeed are on the downloads page (free editions) or in the store (full editions). Web Workbench and NHibernate Designer update automatically through the Visual Studio Extension Manager.

Nightly news, 18 November 2011

Great joy from our operations team this week as the last bit of Community Server is finally excised from our Web site and replaced with a LightSpeed-based support forum that’s faster, more capable and infinitely more maintainable. Check it out! But we’ve also shipped the usual crop of enhancements and fixes to our developer products. Here’s what’s new this week.

LightSpeed

• Added a class containing constants for all aggregate names in the model
• Don’t show a ‘should be cached’ validation warning when associating to reference data across a linked model boundary
• Fix for an issue with subqueries of projections involving soft deleted entities
• Added some new field model information to the metadata API
• Added interceptor support for command execution — this allows low-level diagnostics, retry strategies, etc.

WPF Elements

• Added support for dynamically changing chart axes
• Added alternate Y axis templating for custom axes
• Added a ChartZoomed event
• Fix for IsSelected property on non-joined-up data series (such as scatter graphs)

NHibernate Designer

• Fix for XML mapping issue in Visual Basic
• Use @-strings in Getting Started Fluent NHibernate code
• Added some more validation on identity generator types

These updates are in the current nightly builds. You can get the free editions from the downloads page, and retail editions from the store. NHibernate Designer automatically updates itself from the Visual Studio Gallery.