I'd appreciate input from the community.
I am looking at the CSLA 4.5 data portal vs the current data portal, and the new async/await keywords. I am also thinking about the value of taking existing code to WinRT and reusing it unchanged.
This is all good, because the consumers of the data portal can continue to use BeginCreate, or can opt into the new CreateAsync as desired.
But when I look at the local data portal on Silverlight vs what could be done with async/await, I really don't want to continue the old model.
Specifically, in SL with the local data portal you need this:
public
void DataPortal_Create
(Csla.DataPortalClient.LocalProxy<ItemList>.CompletedHandler handler)
and you must remember to call 'handler' to tell the data portal the method is complete.
Of course in .NET the method would be simpler:
public void DataPortal_Create()
and if I truly embrace async/await it would look like this:
public
Task<T> DataPortal_Create()
And you'd return a Task<T> object as a result of the method.
So here's the question I'm struggling with.
Backward compatibility is important. It is a core value proposition for CSLA.
At the same time, the Silverlight DataPortal_XYZ model is far from ideal, and I don't know that a whole lot of people make extensive use of the local data portal in SL.
So I am strongly considering making the WinRT local data portal use the new DataPortal_XYZ scheme that returns a Task<T>. Or at least making it match the existing void .NET method signature.
Thoughts?
I'd move to Task<T> as long as it offers the same experience across the board and won't need to be changed for a considerable amount of time in the future. One thing I've noticed that dealing with Task<T> is that if you have any exception occur in the task. It can bring down your app. There are some handy extension methods out there that help soft this problem...
Also, couldn't one create some wrappers to help people upgrading? From a code generation stand point, this would be a seamless upgrade.
When using await on a Task, any exceptions in the task flow back to the awaiting code. That's been my experience thus far, and is the intended behavior according to the CLR team.
From an upgrading perspective, there's no doubt that someone could leave the old event-based method intact, and could invoke it using a pretty standard bit of code that wraps an event-based async operation in a task. I actually use this right now in the current async/await code for .NET.
Someone doing an upgrade would just add the new DataPortal_XYZ that returns a task, and we could supply a snippet to implement that method to delegate to the old event-driven method. That'd provide a reasonably quick technique for upgrading.
Though the reality is that most local data portal code from Silverlight won't just work in WinRT, because the WCF and/or REST service proxies created by Visual Studio in WinRT use async/await instead of the Silverlight event-driven model. This isn't a CSLA thing, it is Microsoft changing the async model and the code they generate for us.
Hi all,
My vote goes for Task<T> and make the code similar for .NET/WinRT/SL.
Since SL local data portal won't just work in WinRT I consider this to be a better solution.
Copyright (c) Marimer LLC