Screencast: Working with Views in LightSpeed

Mindscape Screencast

Yet another how-to screencast on working with LightSpeed, we have just published “Views with LightSpeed”.

LightSpeed has always supported working with Views however with LightSpeed 2.2 we have added many enhancements to make them easier to work with. This video helps explore what new additions have been made to improve the developer experience when working with views.

With this screencast you will learn:

  • How to easily work with views in the LightSpeed Visual Studio Designer
  • How to query against views – both with the generated IQueryable and the LightSpeed classic query API
  • How to deal with views that are projections of tables rather than matching existing entities
  • How to with views that return projections that do not match existing entities
  • When having an updatable view would be useful.

Click here to watch how to use Views with LightSpeed.

We added improved view support to LightSpeed for version 2.2 (and in the nightly builds following 2.1). Grab a copy of the latest build of LightSpeed that includes this support here.

Any feedback – either on the view support of on the screencast itself, is greatly appreciated. Drop a comment on this post.

2 Responses to “Screencast: Working with Views in LightSpeed”

  • Great!

    Keep them comming, more complicated video sessions welcomed, or is everything so purely easy with LightSpeed? ;)

    1. “obviously we can/cannot update the sku table” at 6:50 timeframe.

    So Can we or can’t we? Sometimes the voice is really hard to comprehend for non-english speakers, different voice would be welcomed (any lady out there?;-)

    2. I’ve got quick question at the ending:
    When I’ve changed just the SkuCode type will Lightspeed save changes upon UOW commit to both SKU entity and SkuCodes View or just the View? What about concurency problems (someone updated Code in SKU table and another one on SkuCode entity)?

    3. Watching last video and this one I have one really newbie question:

    What is the difference between using View CheapItems and making a Stored procedure to return them.

    As I understand it, using View I’ll automatically get
    collection of strongly typed LS entities and which is LINQified (IQueryable) so it is very easy to work with, but views are mostly static.

    Whereas using Stored Procedure I’ll just get an IList collection (and I can use parameters) but I have to call AsQueryable() extension method on it to use it with LINQ.

    4. in the video, couldn’t you just use LINQ to return entity with “ProductID” == 1? Or is it faster to work with IList and you’ve choosed not to have overhead of IQueryable interface?

    Thank you

  • Hello Nefajciar,

    If you change a SkuCode entity and save changes, it will get saved back to the SkuCodes “table” — which is actually a view. Of course this will only work if it is an updateable view. And you are correct that this could cause concurrency issues if you load both a SkuCode and a Sku, and save one of them back. LightSpeed doesn’t know that SkuCodes and Skus are related. So the scenario shown in the video is a bit artificial — in reality you would probably not have read-write entities which “overlap” in this way, but we wanted to keep the model simple for the video.

    Notice, by the way, that this issue only arises because Sku and SkuCode are different *types*. Skus loaded through different views — e.g. CheapItems and ExpensiveItems — are identified and participate in normal entity concurrency behaviour. So there are actually two different kinds of view support in LightSpeed — views as a way of creating new entity types (SkuCodes), and views as a way of querying existing entity types (CheapItems).

    Regarding the differences between making a view for CheapItems and making a stored procedure for CheapItems: one obvious difference is that a stored procedure can take parameters, e.g. GetCheapItems(decimal maxPrice). Also, a stored procedure can contain a lot more business logic than a view. But a stored procedure is not queryable: for example you can combine a view with a WHERE clause but you cannot do the same with a stored procedure. (This is why the designer-generated wrappers for stored procedures return ILists and those for views return IQueryables.) You can still use sproc return sets with LINQ but this will use LINQ to Objects and be processed client-side.

    The video shows both LINQ-based and Find-based techniques for using views. So using LINQ you can go uow.CheapItems.Where(sku => sku.ProductId == 1) and using Find you can go uow.Find(new Query(Entity.Attribute(“ProductId” == 1) { ViewName = “CheapItems” }). Either is good; it’s a matter of taste (and which version of the .NET Framework you’re targeting) which you use.

    I’ll let JD field the questions about vocal technique since he’s the star of the show…

  • Leave a Reply


Join our mailer

You should join our newsletter! Sent monthly:

Back to Top