You are correct – the LockVersion is tested if it exists and throws an optimistic concurrency exception if it does not match.

Regarding the change tracking in LightSpeed 3.0, this can improve things but only if you’re using an entity directly, not a DTO. We don’t serialize change tracking details with the DTO’s we generate so the best way to check when using DTO’s is to hold two copies. If you had a LightSpeed Entity you could check the change tracker to see what has changed. LightSpeed 3.0 has not changed how you would check the changes when using DTOs.

I hope that makes sense and answers your question – if I have missed something then please let me know :-)

John-Daniel Trask

I’ve only just downloaded LightSpeed, so forgive my naivety. ;-)

I was reading in What’s new in V3 and saw that you seem to have implemented a ‘Fowler’ style version number pattern which works simply by adding a LockVersion property to each domain entity. I assume that this gets incremented each time a successful update takes place, but within that there is a check to see if the LockVersion is the same as it is in the object being persisted? If it doesn’t then the OptimisticConcurrencyException is raised and us as the developer deals with it in an appropriate fashion.

In terms of the ‘original’ state of the entity I’m thinking simply get two copies of the dto on and then compare for any user changes in the current UOW but you mentioned above that “The way we’re currently exposing the change tracking is to use a simple record per property that holds property names and their old + new values. This is built against an entity which is why you would need to currently replicate existing property values if it would be an issue to reconcile against the database version.”

Could you explain a bit about this please and how version 3 may have changed in that sense?

Regards
Colin

You might want to google around for “windows forms mvc” for some general samples and advice — obviously not LightSpeed specific but I get the impression that at this stage you’re more trying to get your head around the pattern. http://stackoverflow.com/questions/654722/implementing-mvc-with-windows-forms seemed a reasonably good collection of links and resources. In particular you should check out the references to Model-View-Presenter (MVP) as an alternative to MVC.

However… I understand why you are reluctant to tackle WPF, but do bear in mind that Windows Forms is basically at the end of the road. It hasn’t been enhanced in the last 3 years and that’s not about to change. This wouldn’t be such a consideration if you could take your MVC/MVP experience gained on WinForms to WPF, but WPF works best with a different architecture known as Model-View-ViewModel (worst architecture name ever). You’re in a tricky situation where you rightly don’t want to have to learn a new UI framework and a new architecture all in one go; but if you learn a new architecture on your existing UI framework, you may not be able to take that knowledge forward, and you’ll end up having to learn the new framework and new architecture all in one go anyway at some later date.

That said, the MVC pattern remains very relevant and elegant in the Web environment, so it’s certainly not wasteful to spend time mastering it. (And for Web work you will definitely be wanting to grok MVC not MVP, as the modern version of the ASP.NET framework has gone the controller route not the presenter route.)

Sorry for the slow reply! You’re correct about needing to hold a copy of the orginal values yourself if you wanted to reconcile with the entity as it stood when you created the DTO from it.

It seems we have two issues here:

1. Only tell me the changes that the user has made against original values – not against what is currently in the database.

The way we’re currently exposing the change tracking is to use a simple record per property that holds property names and their old + new values. This is built against an entity which is why you would need to currently replicate existing property values if it would be an issue to reconcile against the database version.

You could certainly create two DTO’s and hold original values with one. You could also update the templates for the DTO generation to build an Original*PropertyName* field per property. I’m not suggesting this is the best idea, just sharing a way to reduce DTO classes.

2. Reconcile the changes for concurrency violations

Currently we are not offering functionality to do this however the exposure of the change tracking will allow developers to reconcile themselves. So far however general feedback is that most applications deal with concurrency issues in their own way. We would want to help with common case scenarios – which is similar to what L2S is offering from what you’re saying.

We’re pretty busy with LightSpeed 3.0 so post 3.0 we’ll look at a Refresh() capability.

Thank you for your feedback Marko :-)

I’m trying to make a point about the moment of using CopyTo method with DTO and getting that report of changes.

I am expecting model entities will be responsible for change tracking, which means they can be detached and Uow disposed like in the article.

But, if I have a stateless application server and DTOs, after receiving back DTO I have to recreate the entity and use CopyTo method. I will then get a report about changes compared to the current entity copy from the database (I expect a refetch from DB will occur at that process).
I will not get the same report “client modified values” which I would get if I hold on to the original entity which was fetched when client requested start of editing.

Of course, report will not be the same if somebody else changed the record in DB in the meantime, and yes, this is concurrency violation territory. But, for resolving concurrency violation I would be better of if I have the correct information which properties is the client request actually trying to modify (for resolving concurrency I would want to use the rule like LINQ’s RefreshMode.KeepChanges – “forces the refresh method to keep the current value that has been changed, but updates the other values with the database values”).

So, to cope with that situation in a stateless environment you’re suggesting, it looks to me I would need the client to keep a copy of originally fetched values (which I guess means an extra DTO with original values). Or use a stateful application server.

I hope I was a bit more clear now. If I’m missing something, let me know.

I’m not 100% sure what you’re asking here so I will assume you’re wondering how change tracking would work in a distributed environment?

With LightSpeed generating the DTO’s and Entities, you would simply send your DTO down the line and then when it is returned (with or without changes) you can use the CopyTo extension method that LightSpeed generates to apply any changes.

The act of applying the changes means that the change tracking in LS3 will then be able to report what changes have been made.

The is no provision in LS3 for providing change tracking on the client side for DTOs – you simply send the DTO back and let the server side manage the change tracking.

If you wish to do change tracking on the client side (perhaps to test if you should bother sending a DTO back to the server) you would need to apply your own code to test for changes that may have been made to the DTO.

I hope that helps but please let me know if I’ve missed the point of your question.

Cheers.

Thank you for submitting this cool story – Trackback from DotNetShoutout…