I suggest you ...

Improve the request model in LightSwitch

Improve the requests model

When an entity has to be displayed with included data, sometimes LightSwitch performs one different HTTP request per related entity causing clients delays. The model should include all data in the same response. http://social.msdn.microsoft.com/Forums/en-US/lightswitch/thread/cbb87dcd-1648-4445-ae6c-40b2f48399aa

9 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    AnonymousAnonymous shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    1 comment

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • AnonymousAnonymous commented  ·   ·  Flag as inappropriate

        I have to up this, I was going to add a new suggestion but hopefully this gets kicked up the stack.
        I think the user of the post is on the right track. I understand the intention of the architecture of LS and why they might have gone done the route of responsive binding and the perils of locking the ui thread. The offshoot of this is say you have a grid that contains a domain of data

        business
        country(ies)
        state(s)

        if the screen has a query to pull all businesses, it will pull the first 45 by default, imagine I have a list of 100 000 businesses - so far so good. The issue of multiple requests comes in when there is a related entity not in the current ‘related’ set in the screen then LS will query for it to the middle tier - > it has to do this to get the required data. This means that you have the flicker effect in the grid as it builds up the local entity sets and binds to the grid. The more related entities you need to display in the grid the more it will have to go and 'find' the data + the more the uniqueness across the related entity keys the more service requests will be executed across the wire.
        You might then say well that’s not really an issue if the app is internal and say there are a handful of users.

        But... in reality medium size system of 10-20 users across a tunnelled vpn in an office on the other side of the country – perfectly acceptable use case to me, this is where you might start to see a slow down in performance (never mind the gateway wcf threading issue).
        A work around for me in this case is to load all countries and states in the data workspace initialise, then and related entity required for the business entity is pre loaded and effectively what was 50 server requests is down to 3. The issue with this way is what if there are thousands of the related entities that I want to preload – this starts to cause other ‘related’ issues (excuse the pun...), the initial screen load will be a bit slower – especially when using odata.
        A good solution that I can see would be to have an option to create a composite query – so it fetches top 45 businesses, then on the related entities (country and state) still query for country and state, but compose those queries in such a way that it will only query for states where state_id intersects state_id from the current 45 businesses (currently in the client data workspace) state id’s and likewise for country. The option to compose the related key ids against the default ‘getallXXX’ query could be a option to check under load by default in the properties window. This would massively improve user experience.

      Feedback and Knowledge Base