In current nightly builds, you can right-click an entity or property and choose Refactor > Rename. LightSpeed will then not only rename the entity or property, it will also update any existing references. The Refactor > Rename command also gives you the option to keep the existing name as the “database name” (the Table Name for entities, the Column Name for properties), so that you don’t need to remember to remap the entity or property by hand. (Of course, you’ll want to turn this option off if you also intend to rename the column in the database.)

The Refactor menu also offers a couple of other time-saving utilities. One that we’re going to find really handy is Convert to Manual Implementation. This is useful when you want to customise the implementation of a property, for example by adding your own business logic or validation in the setter. Convert to Manual Implementation marks the property to be excluded from code generation in future, and copies the existing generated property code to a partial class to provide you with a starting point that you can then edit to meet your requirements. It even copies attributes such as column name mappings and validation attributes.

Finally, Create Partial Class quickly creates a partial class declaration for you, and Extract Interface allows you to rapidly declare an interface containing selected properties of an entity. (Extract Interface is available only in C# projects.)

One small caveat. Most of these refactorings need access to the generated code, and the code is only generated when you save the .lsmodel file. So if you try to refactor a model with unsaved changes, the designer will do its best, but you may get an error if refactoring needs to access one of those unsaved changes. (Some refactorings may also fail if you’re using a sufficiently radical custom template.)

We’d love to hear your feedback on these refactoring features and whether there are any other similar refactorings you’d like to see in LightSpeed. You can get the latest nightly of the free Express edition here, or retail editions from the store.

The first feature is to show the inheritance graphs of the selected entity or entities. This shows all entities derived from the selected entity, and all of its base types. For example, consider this inheritance hierarchy:

Here’s the same model, with “Contractor” entered into the filter box and the new Show inheritance option selected:

As mentioned, if you enter an intermediate or base class then the designer shows all the derived classes as well. Here’s the model filtered on the “Employee” inheritance graph:

The second new feature is the ability to invert a filter. So if you want to show all entities except a particular one, you can now do so. This can be handy for excluding common base classes which would otherwise have lines to them from everywhere in the diagram, creating clutter. To do this, enter an exclamation mark (!) in front of the filter criterion:

(We don’t have a menu helper for this yet — you’ll just have to remember it!)

Both of these features are in the current nightly build — free Express edition here, or commercial editions from the store.

Let’s look at a simple example of a video sharing site, based on something that came up in the forums recently. In this model, the main entities are Contributions. Each Contribution is associated with a Member (who uploaded it). In addition, there is a many-to-many (through) association between Contributions and Tags, via a ContributionTags through entity.

Now suppose you want to find all the Contributions uploaded by a Member named “t-dogg” and tagged with a Tag named “sheep.” Initially it might seem like you need a join for this, or at least a sequence of nested selects, but in fact you can do it efficiently in a single LINQ query:

from ct in UnitOfWork.ContributionTags
where ct.Contribution.Contributor.Name == "t-dogg" && ct.Tag.Value == "sheep"
select ct.Contribution

The trick here is to work around LINQ’s collection issues by finding a start point where all the associations are many-to-one. In this case, ContributionTag has many-to-one associations with Tag and with Contribution, and Contribution has a many-to-one association with Member. So we can write the query in terms of ContributionTag objects without needing to do a join or an explicit subselect. Then we can project the results along the many-to-one association to Contribution to get the Contributions instead of the ContributionTags.

The core API allows another syntax for the same query which you may find more natural:

UnitOfWork.Find<Contribution>(
  Entity.Attribute("Contributor.Name") == "t-dogg"
    && Entity.Attribute("ContributionTags.Tag.Value") == "sheep");

Here it’s clearer from the Find call that the query is interested in Contributions, not in ContributionTags. Notice also that LightSpeed is able to traverse the ContributionTags collection association without you needing to write an explicit join or subselect.

What LightSpeed can do automatically doesn’t cover every possible join query, and of course if you want to return data from multiple tables you currently have to use a view or a stored procedure rather than a join. But for simple queries that return data from a single table but need to join to other tables only for the “where” criteria, there’s a good chance you can build a LightSpeed query to do the job.

LightSpeed’s eager loading and named aggregate features provide a great way of controlling aggregate loading, and you can easily set up these aggregates via the LightSpeed designer. However, in complex models it’s not always easy to see the aggregates once they’re set up.

We’ve now added a feature to the designer’s filtering capability which allows you to see which entities are participating in a named aggregate, and to display the eager load graph of any given entity. Here’s a simple model for an order management application:

In this case, the Pickup entity eager-loads its associated Warehouse and its associated Shipments collection. That’s not obvious from the display. But if we go to the LightSpeed Model Explorer, filter on the Pickup entity and choose Show load graph, we can see exactly what is going to get loaded along with a Pickup:

The load graph feature chases cascading eager loads, so if you have a chain of entities you will be able to see the entire load graph.

Another feature we’ve added is the ability to see which entities participate in a named aggregate (that is, an aggregate which is only conditionally loaded). This doesn’t show the load graph per se, but it enable you to rapidly zero in on which entities are involved in a named aggregate. To do this, select Aggregate from the Filter By menu or enter the aggregate name prefixed by the @ symbol. For example:

We hope that these features will be useful to you in visualising what will get brought in when you load a particular entity. Download the latest build of the free Express edition (or get a full copy from the store) and let us know what you think!

In recent builds of the designer we’ve added a tagging facility where you can associate tags with each entity. Once you’ve done this, you can filter to show just the entities with a given tag.

Here’s a simple example based on an order processing model. (In reality you’d only use this feature when your model is too complex to fit on one screen, but I wanted to keep the screenshots simple!) Here the entities fall into two sub-domains, Sales and Logistics, with one or two entities appearing on both sub-domains. We can represent this by tagging each entity with the sub-domain it falls into (multiple tags can be separated by commas):

Now when we want to focus on a particular sub-domain, we can go to the LightSpeed Model window and use the Filter box to show only the tags we’re interested in. To tell the Filter box that you’re filtering on tags rather than names, prefix the filter with a # sign (you can use the Filter By menu to do this for you). Here’s how the model looks after entering #sales to filter on the “sales” tag:

You can include multiple tags in the filter, again by comma-separating them. And of course you can still also filter by entity name as previously discussed; and we’re adding eager load graph visualisation.

We hope this navigational feature will help you to tame your larger models. If you’ve got big complex models and you want to give it a go, you can download the latest nightly from the store (and of course the free Express edition here if you’re getting lost even in an 8-table model!).

To recap, currently LightSpeed ships with the following samples:

• An ASP.NET MVC sample
• A LINQ Queries sample allowing developers to see how to write specific queries using the LINQ API
• A Queries sample allowing developers to see how to write specific queries using the native LightSpeed Query API
• A simple localization sample
• The Mats challenge application showing how to efficiently fetch data
• An ASP.NET poker website sample
• An ASP.NET ecommerce store sample
• A Visual Basic sample

Now these certainly need some freshening up – the MVC sample is a bit too complicated and currently uses an older drop of ASP.NET MVC. Most of the other samples target .NET 2.0 and therefore don’t use LINQ querying which is becoming the mainstream way that users wish to interact with LightSpeed.

We have had several requests for more standard ASP.NET samples (not ASP.NET MVC), IoC samples as well as larger more sophisticated samples. I thought it was best to put the question out to you, the LightSpeed developer – what would you find helpful? What about how we deliver them – how would you like them (we currently run of SQLite to save you setting up a database for example)?

I’d really appreciate your thoughts :-)

• You no longer need to use SignatureVersion=1 when accessing M/DB; the default signature version and method will just work.
• The issues around single quotes in queries, and around sorting and starts-with, are resolved.

At the moment there appears to be an outstanding issue with paging, but because M/DB doesn’t impose a limit on the size of responses the way Amazon does, you can work around this by paging on the client. M/Gateway are looking into this to see if it can be resolved.

We’d like to thank Rob Tweed of M/Gateway for his help and his rapid response on this. If you’re using SimpleDB and you want a fast, convenient test-bed, do check out M/DB.

A consequence of this is that if the unit of work is hidden away in the repository class, so is the unit of work lifecycle and sharing logic. Your application can’t control the lifecycle as it would do if it constructed the unit of work directly.

But we couldn’t build a particular lifecycle into the base LightSpeed repository class: different environments need different lifecycle and sharing logic. For example, in a Web application, you want each request to get its own unit of work. You don’t want units of work hanging around from one request to the next, and you don’t want simultaneous requests sharing the same unit of work. In a Windows Forms application, you would need a different and potentially application-dependent strategy. So it’s necessary instead to encapsulate this lifecycle and sharing logic in a strategy class. Then the application can just delegate selecting the correct unit of work to the strategy class, and stop worrying about lifecycle concerns.

In LightSpeed, these lifecycle and sharing strategy classes are called unit of work scope classes. We provide two of them out of the box, a unit-of-work-per-request strategy for Web applications, and a unit-of-work-per-thread strategy for batch tools.

Scope classes inherit from UnitOfWorkScopeBase, an abstract class which basically defines just one interesting property, Current. The Current property represents the unit of work that should be used in the current situation. A concrete scope class will override Current to provide creation and partitioning logic appropriate to the particular strategy.

Let’s look at a common example. As noted, a Web application wants a unit of work per request. That is, we want to be able to write page, controller or presenter code that looks like this:

var products = this.Repository.GetAllProducts();
MakeSomeChanges();
this.Repository.SaveChanges();

and know that within any given request all our entities will be part of the same unit of work (so that associations will be wired up correctly, etc.), and that SaveChanges will be applied to that same unit of work; but also that different requests will get different unit of work instances, so that the SaveChanges() call won’t save changes currently under way in other requests

How can we encapsulate this in a scope class? The answer is to implement Current something like this:

TUnitOfWork current = (TUnitOfWork)HttpContext.Current.Items["UOW"];
 
if (current == null)
{
  current = LightSpeedContext.CreateUnitOfWork();
  HttpContext.Current.Items["UOW"] = current;
}
 
return current;

The strategy checks to see if there is already a unit of work associated with the current request. If so, it returns that existing unit of work. If not, it creates a new one and associates it with the current request, so that subsequent calls to Current as part of the same request will return the same unit of work.

Then the repository will internally have an instance of this scope class, and use its Current unit of work to handle requests:

public class StoreRepository : RepositoryBase<StoreUnitOfWork>
{
  public StoreRepository(string configName)
    : base(new PerRequestUnitOfWorkScope<StoreUnitOfWork>(
      new LightSpeedContext<StoreUnitOfWork>(configName)))
  {
  }
 
  public IList<Product> GetAllProducts()
  {
    return UnitOfWorkScope.Current.Products.ToList();
  }
}

So not only is the application code uncluttered by details of the persistence mechanism and the unit of work, the repository methods are free of lifecycle and partitioning details as well. All of that stuff is hidden neatly away in the scope class. In particular this facilitates testing because the HttpContext-dependent scope class can be swapped out for a simple scope class (see http://www.mindscape.co.nz/blog/index.php/2008/05/12/using-the-unit-of-work-per-request-pattern-in-aspnet-mvc/ for more info.

And that’s all there is to scope classes. A lot of customers find them a bit confusing but really you only need to know two things: first, they’re just simple wrappers that do a little housekeeping and a little encapsulation, and second, you only need them if you’re using the repository pattern, or if you want to save writing the HttpContext wrapper code yourself. Many LightSpeed applications will never need a scope class at all.

Fortunately, MGateway Developments have a free, “plug-compatible” alternative called M/DB, which not only allows you to have local test versions of SimpleDB but can also be used in production to break through some of SimpleDB’s limitations. It’s provided as a handy virtual appliance, which makes it a snap to set up locally.

We’ve now updated LightSpeed and SimpleDB Management Tools to support M/DB. In SimpleDB Management Tools, you now can supply a URL to a M/DB instance. You can then work with that instance in Server Explorer and the Query window just as you now do with the Amazon service. You can set up connections to multiple M/DB instances and have them alongside your connection to Amazon itself.

In LightSpeed, we’ve added elements to the connection string to allow you to override the default Amazon URL and point to a M/DB instance instead. Simply add the following element to your connection string:

Url=http://xxx.xxx.xxx.xxx/mdb/request.mgwsi

and you’ll be good to go.

If you want to try out LightSpeed against M/DB, grab the latest nightly from here or from the store.

To get the updated version of SimpleDB Management Tools, go here for the free edition or to the store for the unlimited edition.

UPDATE: In the M/DB “virtual appliance” (build 21) there were some compatibility issues noted in an earlier version of this post. These issues are now fixed but you will need to download and install M/DB build 26 or above to make it work seamlessly with LightSpeed and SimpleDB Management Tools.

It’s a bit late but now that we have some photos from the evening it seemed like a good time to make a post about the New Zealand Hi-Tech Awards. Two weeks ago Jeremy and I went to Christchurch to attend the Hi-Tech awards – we hadn’t entered Mindscape in the awards this year but I was put forward for the Young Achiever award.

I was fortunate enough to be a winner of the Young Achiever category along with Andrew Graham. Endace sponsored this award and so the award was given by Neil Hopkins of Endace (on the left):

Praise needs to go to the organisers and sponsors of the awards – celebration of business success and highlighting the importance of creating innovative technology companies in New Zealand is important. A memorable quote of the evening was that we need to be creating global businesses – something that I believe Mindscape truly is – over 95% of our customers are not in New Zealand. Thanks of course also goes to the rest of the Mindscape team and all those involved in the other ventures that we are part of.

Overall it was a great evening – we met some very interesting people, connected up with some we hadn’t seen in a while and stayed up way too late (in typical geek fashion, back at the hotel room afterwards Jeremy and I played some Unreal Tournament 2004 to which it became apparent I am not very good at playing when tired and full of wine!). Good Times!

Read more about the New Zealand Hi-Tech Awards here.