Home » Blog

Archive for May, 2009

Visualising eager load graphs in the LightSpeed designer

Tagged as General, LightSpeed

Understanding what gets loaded when is important to the efficient use of an object-relational mapper. Load too little, and you can end up making lots and lots of round trips to the database. Load too much, and you can end up hauling in dozens of entities when you only wanted one or two.

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!

Add your comments
Posted by Ivan Towlson on 27 May 2009

Sub-views in the LightSpeed designer

Tagged as LightSpeed

We’ve been continuing to add navigational aids to the LightSpeed designer and one recent feature can be used to implement a simple form of sub-views. By a sub-view I mean that you can filter down to just a limited set of entities — for example, a Sales sub-view, a Logistics sub-view, etc.

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!).

Add your comments
Posted by Ivan Towlson on 26 May 2009

Feedback wanted: LightSpeed 3.0 samples

Tagged as LightSpeed

With every release of LightSpeed we aim to provide improved sample applications. I’m tasked with the improvement of the existing sample applications as well as adding some new samples for developers to learn from and thought it best to ask the users to find out what you want.

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 :-)

Add your comments
Posted by John-Daniel Trask on 24 May 2009

M/DB support update

Tagged as LightSpeed, SimpleDB Management Tools

Earlier this week we announced LightSpeed and SimpleDB Management Tools support for M/Gateway’s M/DB, a free database which is “plug-compatible” with Amazon’s SimpleDB. At the time I noted a couple of issues and limitations. I’m glad to say that M/Gateway have very quickly addressed these, with a new build (build 26) available for download now. With this new build:

• 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.

Add your comments
Posted by Ivan Towlson on 21 May 2009

Unit of work scoping in LightSpeed

Tagged as LightSpeed

A common pattern for working with persistent storage is the Repository pattern. This typically takes the form of a class which encapsulates all of the data access code, usually instantiated as a member of a common base Page or (for MVC/MVP architectures) Controller or Presenter class. In LightSpeed terms, the unit of work is hidden behind the Repository facade, so that your application code deals only with the domain objects.

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.

Add your comments
Posted by Ivan Towlson on 19 May 2009