The behavior of the data portal has changed quite a bit from 4.3 to 4.5. This is because the data portal in Silverlight now works the same as in other platforms, and because BeginXYZ and XYZAsync now work the same.
One primary area of change is when calling BeginCreate or BeginFetch and using the local data portal, the calls aren't forced to be async. In other words, the data portal doesn't spin up a background thread for the 'server-side' code.
This is because the DataPortal_XYZ methods can now be declared with the async keyword and so can make use of all the cool new async features in .NET 4.5.
Right now I've recorded this behavior as a bug, but as I look at "fixing" the bug, I'm not sure that a fix is actually a good thing.
In other words, right now the data portal is the same for all platforms. And BeginCreate/BeginFetch are the same as CreateAsync and FetchAsync - they all follow the same basic rules.
If I make the BeginCreate/BeginFetch methods spin up threads to call the data portal, then I do preserve the 4.3 behaviors for the local data portal, but there won't be parity between those methods and their CreateAsync/FetchAsync counterparts.
I'm torn between backward compatibility and overall functional parity.
As a result I am interested in input. Do you think it is better to preserve backward compatibility in this case, or is it better to require changes to existing BeginXYZ code to bring that code more in line with the new capabilities provided by the async/await keywords?
Or I suppose an option is for CreateAsync/FetchAsync to spin up a thread too - but in many cases that just creates overhead that isn't necessary. So I really don't think that's a good option.
In other words, right now the data portal is the same for all platforms. And BeginCreate/BeginFetch are the same as CreateAsync and FetchAsync - they all follow the same basic rules.
(...)
I'm torn between backward compatibility and overall functional parity.
Hi Rocky,
I think functional parity is the way to go. I know you try to avoid breaking changes as much as you can, but this isn't the first and it won't be the last. This only affects Silverlight code (and WP? and WinRT?) and Silverlight code is very specific. I believe some old users might prefer no breaking changes but new users might find functional parity easier to deal with
As I use generated code, for me it's just a question of changing or not changing the templates.
I vote for the functional parity.
While i fully agree with is what stated, i want to add that when my projects have to be ported to 4.5, they will need a refactoring of the codebase, so this can be taken into account with.
As time goes on we will all be moving towards the new capabilities, so functional parity is a good thing. I wouldn't want to spin up threads just because. Is the creating of unnecessary threads the 'async behaviors' you're concerned with?
I want to make sure everyone understands that this is not just a SL change.
The BeginXYZ methods used to spin up a thread for WPF and Windows Forms as well, so the change to make them work like the XYZAsync methods affects everyone other than web developers (if you used the BeginXYZ methods).
I vote for functional parity as well.
After discovering this behavioral change the hard way. I vote for functional parity too.
I vote for functional parity (and thus consistency).
We have spent quite a bit of time with 4.5 by now (under both .NET and Silverlight) and after becoming comfortable with the Async behaviour, it would be highly preferable if this is consistent throughout without there being "gotcha''s if you are running a different portal, or technology platform.
A team member has actually commented saying "why don't we just have a single async factory and get rid of the synchronous and DataPortalResult overloads".
Copyright (c) Marimer LLC