Archive for February, 2009
LightSpeed and Mono
Tagged as LightSpeedWhile most Windows developers are used to the .NET Framework being a standard part of the system, Microsoft doesn’t offer an official release which targets Linux or OS X. The Mono Project was set up to bridge this gap, and provide an open source, cross platform .NET implementation. It supports most of the same capabilities that the standard .NET Framework supports, and even allows for easy interop with native frameworks such as Cocoa under OS X (using Cocoa#).
We have heard from a number of people querying if you can use LightSpeed when developing for Mono. Up until now, we have been somewhat naive to this, however the Mono site promotes "Binary Compatible", the FAQ tells me that you can run binaries produced by the Microsoft compilers and the Mono Migration Analysis tool only popped up a couple of warnings, so I thought we should certainly look deeper at this!
So lets start with a basic model, a film festival.
So a simple test over this model using LightSpeed would be to fetch out some entities, and perform an insert and update, so some example code might be:
Of course this runs happily under Windows, but how about under OS X using Mono? Lets start with the simple case, taking compiled output from Visual Studio on Windows and trying to run it under Mono on OS X.
No problem – but how about if we natively compile the same code using the Mono compiler?
Looks great, but how does it run?
Very exciting :)
We have started targetting Mono for all future nightly builds and we are integrating a fuller suite of tests for Mono into our build process – so take LightSpeed for a test drive on Mono today and let us know how you find it! Remember to check out the Getting Started screencast to learn how to get up and running quickly with LightSpeed and post your feedback in the forums! :)
Jeremy
Comparing .NET O/R Mappers

We get frequent inquiries about how LightSpeed compares with other object relational mapping frameworks that are available. Last year we published our comparison matrix that compared LightSpeed, LINQ to SQL and LINQ to Entities. We’ve now updated the comparison matrix to also include EntitySpaces and Telerik OpenAccess.
See the product comparison here.
First off, this is not an exhaustive feature comparison – there are many small and handy features included in all object relational mappers which didn’t get included (LightSpeed included). For example, while EntitySpaces does not support ASP.NET Dynamic Data, it does include templates to rapidly create a CRUD site should you want one which achieves a similar goal to Dynamic Data. This matrix is designed to give a rough idea of how the products compare.
We have only included LINQ to SQL, LINQ to Entities, EntitySpaces and OpenAccess because of space constraints. Thanks also to Mike from EntitySpaces who helped in clarifying the feature set available with EntitySpaces.
Consider: Pricing
Features are handy, but need to be considered against price. At the time of writing (and please remember prices are always subject to change), the products in our matrix are priced as follows:
LightSpeed – Free Express edition; commercial editions up to $499 USD (not per developer, often the entire price for your whole team)
LINQ to SQL / LINQ to Entities – Included in the .NET Framework and Visual Studio
EntitySpaces – Up to $299 USD per developer (company fee of $499 if you want source)
Telerik OpenAccess – Free for open source databases; commercial licenses up to $599 USD per developer
Pricing is a complex thing and we’ve only included the cheapest and the most expensive editions in the ranges listed but hopefully it helps in the comparison of the object relational mappers available at the moment.
Consider: Frequency of updates
Also consider the frequency of enhancements. Microsoft enhancements to their LINQ-to-X products are tied to .NET framework releases and therefore result in needing to use workarounds for a considerable amount of time. LightSpeed, EntitySpaces and OpenAccess all get updates several times a year, resulting in faster turn around of enhancements. Mindscape has also offered nightly builds of LightSpeed for some time and therefore developers get access to new features as they’re built.
I hope that helps people when deciding on the object relational mapper for their next project. Please leave any comments you have about this comparison as comments on this blog post.
Planning LightSpeed 3.0 – what do you want?
With LightSpeed 2.2 out the door it’s time to start planning our next version.
We receive a heap of feedback on enhancements and improvements that people would like to see throughout the life of LightSpeed – every single request gets discussed and put on a feature backlog and then prioritised for a future release. We already have a big list of things that we want to achieve with LightSpeed 3.0 but now is the best time to let us know what major features you would like to see.
So – post a comment telling us what you want to see in the next generation of LightSpeed. No feature too small or too big.
In the near future we’ll publish the planned roadmap for the journey to LightSpeed 3.0.
LightSpeed 2.2 released
We’re pleased to announce the release of LightSpeed 2.2, available for download today. Here’s what’s new in this release.
Stored procedure support
You can now use stored procedures to retrieve entities from the database. This allows you to use pre-defined queries, to create composite or projection entities or to incorporate complex logic in your queries. Support for stored procedures is both in the LightSpeed core product and the Visual Studio 2008 integrated designer:

The designer will generate helper methods for stored procedures so you don’t have to, or you can write your own stored procedure calls if you would prefer not to use the designer. In this screenshot we have dragged on a stored procedure that has a parameter “maximum” which generates the following code:
public IList<Sku> InexpensiveProductsVariable(int maximum) { ProcedureParameter maximumParameter = new ProcedureParameter("maximum", maximum); ProcedureQuery procedureQuery = new ProcedureQuery("InexpensiveProductsVariable", maximumParameter); IList<Sku> valueToReturn = Find<Sku>(procedureQuery); return valueToReturn; }
Stored procedures are supported for SQL Server 2005, SQL Server 2008, Oracle, MySQL and, via functions, PostgreSQL.
Watch the “working with stored procedures” screencast
Multiple views per entity type
On a related note, although LightSpeed has always been able to use views, you’ve previously had to define a specific entity type for each view. In 2.2, you can use a view as a pre-defined query, so that a single entity type can be loaded through multiple different views. For example, a Product entity could be loaded through the BargainProducts or Top10Products view as well as through the Products table.
In this screenshot we see an example of a View over the table SKU that returns the cheap items in the table:

The designer will also generate an IQueryable
var items = from item in uow.CheapItems where item.ProductId == 1 select item;
If you’re using .NET 2.0, which LightSpeed fully supports, and need to use the non-LINQ API:
Query query = new Query(Entity.Attribute("ProductId") == 1); query.ViewName = "CheapItems"; IList<Sku> results = uow.Find<Sku>(query);
Watch the “working with views” screencast
ASP.NET Dynamic Data support
You can now create ASP.NET Dynamic Data sites off your LightSpeed models. This can be a great way to get an admin site or a simple intranet site up and running quickly and with little or no maintenance required. As Scott Hanselman mentioned, for the right sort of applications, “you can get a metric ass-load of work done in a short period of time.” Many folk commented on his post that it’s a shame LINQ to SQL is being put on life support but thankfully LightSpeed slots easily into place as a replacement.
Amazon SimpleDB support

LightSpeed is the first .NET O/R Mapper to support Amazon SimpleDB out of the box. Earlier we released SimpleDB Management Tools that provides Visual Studio integration support for SimpleDB so that LightSpeed developers can work with the Visual Studio LightSpeed Designer with SimpleDB.
Read more about working with LightSpeed and SimpleDB (note: this post was prior to LightSpeed 2.2 being released)
Designer improvements
We’ve added a number of options for customising the generated code, including making properties internal and/or virtual (useful if you use a mocking framework for your unit testing), placing CLR attributes on the generated properties and even excluding properties from being generated at all (useful if you have some special domain logic that needs to go in the property implementation).
The designer can now also generate Windows Communication Foundation data contracts for you.
Finally, we’ve added a Get Started command which shows you sample LightSpeed starter code, customised to your model and language ready to copy and paste. It also provides links to online learning and support resources in case you have any more questions! To get at this screen, just right click the design surface and choose Get Started.

And many more enhancements
Plus lots of other smaller tweaks, improvements and fixes. We always publish a complete change log of the changes made in each point release.
LightSpeed 2.2 Express Edition is available for free download, and existing customers can upgrade free at the store.
Let us know what you think – drop a comment on this post!
Attached behaviours in WPF
Tagged as WPFWPF is all about composition. Good WPF code is made up of lots of small, specific, reusable components — things like value converters, commands, styles and selectors — brought together with XAML. However, one area where there’s no obvious built-in means of composition is behaviour. You can’t style event handling the way you can style appearance. So traditionally, customising the behaviour of a control means writing a new control (though hopefully reusing the existing one!). This is a bit heavyweight, and leads to a combinatoric explosion if you have a bunch of optional behaviours which you want to be able to turn on and off on a case-by-case basis.
Attached behaviours are a solution to this problem. Using attached behaviours, you can bundle up a piece of event-handling logic in a small, specific, reusable package which you can then apply to controls using XAML — even using styling!
Let’s consider a simple example. Suppose we want to create a text box that only allows the user to enter digits. We could of course hook the PreviewTextInput event and block all non-digit input:
<TextBox PreviewTextInput="TextBox_PreviewTextInput" />private void TextBox_PreviewTextInput(object sender, TextCompositionEventArgs e) { foreach (char ch in e.Text) if (!Char.IsDigit(ch)) e.Handled = true; }
This approach works fine as a specification of behaviour for that one specific text box, but it’s not reusable or composable. First, the event handler has to be in the code-behind for the window, so if we want digit-only text boxes in another window, we end up duplicating the code. Second, we can’t compose this with other behaviour that triggers on the PreviewTextInput event: a control can’t have two handlers for the same event. Third, if there’s logic that depends on multiple events (say, a key-down/key-up pair), the behaviour is no longer atomic: we might remember to hook up the key-down event but forget the key-up event. Fourth, it can’t be hooked up to the control using the normal WPF customisation system of styles and templates.
The solution is to rework the event handling code as an attached behaviour. An attached behaviour is simply an attached property that, when it is set on an object, does something to that object. (As distinct from typical attached properties, which just associate some data with the object for something else to consume. In fact, attached behaviours may be totally uninterested in the value of the property they’re masquerading as — they may care only about who they’re being attached to.) Attached behaviours work their magic in the property changed callback, which is called by WPF when the value of the property on an object changes — of greatest interest, when the value of the property on an object is first set. Let’s take a look, starting with the attached property boilerplate.
public static class InputBehaviour { public static bool GetIsDigitOnly(DependencyObject obj) { return (bool)obj.GetValue(IsDigitOnlyProperty); } public static void SetIsDigitOnly(DependencyObject obj, bool value) { obj.SetValue(IsDigitOnlyProperty, value); } public static readonly DependencyProperty IsDigitOnlyProperty = DependencyProperty.RegisterAttached("IsDigitOnly", typeof(bool), typeof(InputBehaviour), new UIPropertyMetadata(false, OnIsDigitOnlyChanged)); }
There’s nothing unusual going on here — this is a completely boilerplate attached property definition, straight out of the Visual Studio snippet except for the addition of a property changed callback named OnIsDigitOnlyChanged. What does that callback look like?
private static void OnIsDigitOnlyChanged(object sender, DependencyPropertyChangedEventArgs e) { // ignoring error checking TextBox textBox = (TextBox)sender; bool isDigitOnly = (bool)(e.NewValue); if (isDigitOnly) textBox.PreviewTextInput += BlockNonDigitCharacters; else textBox.PreviewTextInput -= BlockNonDigitCharacters; } private static void BlockNonDigitCharacters(object sender, TextCompositionEventArgs e) { foreach (char ch in e.Text) if (!Char.IsDigit(ch)) e.Handled = true; }
What’s going on here? When InputBehaviour.IsDigitOnly is set on a TextBox, if it’s being set to true, we hook up the TextBox’s PreviewTextInput event (giving it the same handler as in the original example). If it’s being set to false, we remove that event handler. So what happens when WPF loads the following XAML?
<TextBox local:InputBehaviour.IsDigitOnly="True" />As WPF loads the XAML, it sets the InputBehaviour.IsDigitOnly property to true on the TextBox. That in turn triggers the property changed callback. And that in turn hooks up the TextBox’s PreviewTextInput event so that it will reject all non-digit input. We’ve got the same behaviour we had in the original one-off event handling example, but now it’s in a nicely packaged, reusable form. We can set IsDigitOnly on text boxes from different windows. We can compile the InputBehaviour class into a library and reuse it from other assemblies, in pure XAML. We can compose it with other behaviours and we can even bundle it up in a style:
<Window.Resources> <Style x:Key="BigHonkingDigitOnlyTextBox" TargetType="TextBox"> <Setter Property="FontSize" Value="36" /> <!-- big --> <Setter Property="local:InputBehaviour.HonkOnKeyPress" Value="True" /> <!-- honking --> <Setter Property="local:InputBehaviour.IsDigitOnly" Value="True" /> <!-- digit-only --> </Style> </Window.Resources> <StackPanel> <TextBox Margin="10" Style="{StaticResource BigHonkingDigitOnlyTextBox}" /> </StackPanel>
If you want to learn more, there’s a reasonable amount of material out there about attached behaviours, describing implementation techniques and going much further into possible applications than I’ve discussed here. Josh Smith’s blog is a good place to start, and John Gossman has an article about how it’s applied in Expression Blend. At any rate, it’s a handy trick and a good way to refactor repetitive event handling code. And the same technique can also be used for some other neat little tricks. We’ll talk about those in a future article.
Categories
BrainDump (1)
Community Code (4)
Events (16)
F# (14)
General (53)
Lab Samples (2)
LightSpeed (268)
MegaPack (8)
News (71)
NHibernate Designer (26)
Nightly news (52)
Phone Elements (24)
Products (87)
Projects (5)
Screencast (6)
SharePoint (3)
Silverlight (14)
Silverlight Elements (66)
SimpleDB Management Tools (20)
Visual Studio (9)
VS File Explorer (7)
Web Workbench (39)
WPF (44)
WPF Diagrams (57)
WPF Elements (110)
WPF Property Grid (32)



Posted by Jeremy Boyd on 12 February 2009


