Jun
4
Written by:
Michael Washington
6/4/2011 6:25 AM
One of the greatest benefits to using LightSwitch, is that it automatically manages data integrity when multiple users are updating data. It also provides a method to resolve any errors that it detects.
The first issue is very important, and with most web applications, it is not handled. Simply, the last person to save a record overwrites any other changes, even if those other changes were made after the user initially pulled up the record. The second issue, a method to resolve this situation, is priceless, because the code to create the “conflict resolution process” is considerable.
This blog post does not contain any code examples, because there is no code for you to write to get all these features!
Log in and use the Things For Sale example located here: http://lightswitchhelpwebsite.com/Demos/ThingsForSale.aspx
When we first pull up an existing Post, the Price of the car is $6,500.00.
Change the price to $7,500.00. Do not save yet.
Open a new web browser window and pull up the record, the price is still $6,500.00.
Go back to the first window, and save the record (the price in the database is now $7,500.00).
Now, go to the second window and try to save, you will get a box that detects that the data has changed since the last time you saw it.
Most importantly, it detects and highlights the discrepancy of each individual field, and provides a mechanism to resolve each one.
LightSwitch, Because Your Business Data Is Important
Your business data is important. This sort of integrity checking is expected of web professionals, but try this experiment on your web application, and don’t be surprised if it simply uses the last value.
The reason this is important, is that the second to last user will report to management that they updated the Price of the car. The last user will tell management that they were in the system and never saw the Price change. The programmers will then be instructed to implement logging. If they had logging, they would be able to determine what went wrong, but that would not prevent the problem from happening again.
By using LightSwitch, you avoid the problem in the first place.
4 comment(s) so far...
Hi Michael
Our company has decided to invest on LightSwitch technology and develop our next generation product line. We are now in the process of exploring all the potential and deciding what technologies should we adopt along with LightSwitch to have a full-featured development solution.
For example we are going to look for control suites to extend LightSwitch, Reporting solution etc.
One of our worries is ORM. LightSwitch is using, if I am not mistaken, EF under the hood. EF's lack of "maturity" makes us keep an open eye for other potential solutions. Either using RIA services or extension DataSources when available.
Regaring your article, as concurrency is one of our concerns, I would like to ask you if the behaviour you describe in this post is implemented by LightSwitch's native EF support or at a higher level. I mean if one uses either RIA Services with another ORM (XPO, NHibernate, DevForce, Fluent) or an extension DataSource is the above described behaviour insured or is it lost? I mean most of the aforementioned ORM solutions implement some kind of concurrency mechanisms and there may be conflicts.
We would appreciate any input.
Thanks in advance, at least for the time spent to read all these :-)
Kostas Christodoulou
By kchristo on
6/21/2011 10:42 PM
|
@kchristo - My understanding is that concurrency features come from EF. Please post any further questions to the forums because the blog comments is a hard place to have a conversation :)
By Michael Washington on
6/22/2011 4:42 AM
|
I'll be visiting the Forums for further discussion but it would help if this "landing page" can be used to quickly confirm or deny or provide a link or reference to enabling this type of concurrency checking capabilities that can occur between multiple instances published as 2-tier desktop apps that may be able to share the same instance of SqlExpress.
Anybody cover this scenario?
By Clinton Gallagher @virtualCableTV on
3/5/2013 3:21 PM
|
Kostas;
I am going down the same path you have already traveled. :-) I was enamored with the quick build features, but the concurrency issue brought a few worries up for me. How many users could I safely/realistically deploy my application to with this older style of concurrency check? I was pretty shocked after running a SQL trace on an Update statement.
I'd appreciate any other major flags or pointers on what I should investigate along these lines.
Thanks,
Carla
By Carla on
4/1/2013 2:36 PM
|