The Anatomy of a LightSwitch Application Part 3 – the Logic Tier

re: The Anatomy of a LightSwitch Application Part 3 – the Logic Tier

dvr — Wed, 14 Nov 2012 12:18:23 GMT

Hi,

I'm comming into LS dev and to be honest these sort of statements do offer a bit of concern:

The LightSwitch developer doesn’t need to know about the underlying data access technologies employed in order to work with data or to write business logic.

re: The Anatomy of a LightSwitch Application Part 3 – the Logic Tier

Gerardo Abal — Wed, 29 Aug 2012 11:40:43 GMT

What about "Custom Operations (future)" in LightSwitch 2012?

I'm looking for how to define method on LightSwitch and then be able to call it by a OData client, not only CRUD actions.

Has someone know a workaround to achieve this?

re: The Anatomy of a LightSwitch Application Part 3 – the Logic Tier

Karol Zadora — Tue, 05 Apr 2011 22:30:11 GMT

Ivan,

When submit pipeline encounters an error different from concurrency error the SaveChanges_ExecuteFailed is method called--before the response is sent to client. We do not do any entity refresh there; the data workspace is left as it was just before the (unsuccessful) persistence of changes was attempted. It has all changes etc.

SaveChanges_ExecuteFailed is designed to give you an opportunity to log the error or do something similar. It is not possible to modify the DataWorkspace and re-try the save operation from there. When SaveChanges_ExecuteFailed is called, the pipeline is essentially done. No matter what you do, the client will be told that the changes were not submitted successfully.

On the other hand, on the client side the changes inside the client-side DataWorkspace will be preserved too. The user can make additional changes (or not) and re-try the submit operation. This is completely valid scenario.

Hope that helps,

Karol Zadora

LightSwitch development team

re: The Anatomy of a LightSwitch Application Part 3 – the Logic Tier

_ivan — Fri, 25 Mar 2011 17:08:17 GMT

So what happens to Data Workspace when SaveChanges_ExecuteFailed is triggerred by some server side error other than concurrency violation?

Do you refresh entities (the ones which are refreshable)?

Do you reuse Data Workspace? You still have a change set which may or may not be valid.

Can User cancel out from the save operation and make additional changes later without closing the workspace? Can user make changes to the existing workspace in this case and try saving the change set again? These were the major pain points in LINQ to SQL 3.5 and in EF v1, because change sets were neither detachable nor modifiable.

re: The Anatomy of a LightSwitch Application Part 3 – the Logic Tier

Andy H — Wed, 15 Sep 2010 12:28:14 GMT

An ISO can be found under related resources in microsoft download center.

www.microsoft.com/.../details.aspx (scroll down to related resources)

direct link (probably not working)

download.microsoft.com/.../VSLightSwitchBeta1ENU1.iso

re: The Anatomy of a LightSwitch Application Part 3 – the Logic Tier

Kindor — Tue, 31 Aug 2010 17:55:33 GMT

@Vishwas were you able to get an .iso for the beta?

re: The Anatomy of a LightSwitch Application Part 3 – the Logic Tier

vishwas — Sat, 28 Aug 2010 12:26:34 GMT

is there a way to downlaod iso file for lightswich. I can not install it due to proxy problems

re: The Anatomy of a LightSwitch Application Part 3 – the Logic Tier

Lux444 — Fri, 27 Aug 2010 18:24:48 GMT

> Although custom operations are definitely a part of the LightSwitch architectural roadmap, they did not make it into the first release.

By "first release" You mean "Beta 1" or "RTM 1"?

re: The Anatomy of a LightSwitch Application Part 3 – the Logic Tier

ADefwebserver — Thu, 26 Aug 2010 17:42:59 GMT

Thank You! Keep them coming.