Hi,
I was trying to upgrade my application from CSLA 4.3.13 to CSLA 4.5, and the code didn't Compiled.
Noticed that
public virtual T Save() of abstract class BusinessBase<T>
is changed to
public T Save() of abstract class BusinessBase<T>
Is there any specific reason of removing the Virtual from the method signature.
It is because the method you should override now is SaveAsync as this is called for BOTH sync and async save method.
public async virtual System.Threading.Tasks.Task<T> SaveAsync(bool forceUpdate)
Thanks for the updates.
I saw that method, but as i mentioned that we have an existing application, changing the name from Save to SaveAsync will lead to rework on entire application.
Won't it be a good idea to keep supporting the Sync method Override?
The point of override method is just that - you want to override the default behavior and alter/replace with your own.
The code that you would override is moved to SaveAsync - hence if we allowed you to override Save then YOUR application would potentially have a different behavior than it did before - as the code that you want to override is moved. So for your app to behave as before you must update your code to override SaveAsync.
I know this is an old thread, but I'm having the same difficulties during an upgrade from 3.8 -> 4.5
I found out the SaveAsync method which is the only overridable Save method now, could be decorated with an async and await keyword, then the behavior remains the same when you call the Bo.Save() method from your old code.
it is possible to move your behavior from old Save() method to the new SaveAsync.For me it was about catching some specific exceptions:
protected override async System.Threading.Tasks.Task< Achterstandswijk> SaveAsync(bool forceUpdate, object userState, bool isSync)
{
try
{
return await base.SaveAsync(forceUpdate,userState,isSync);
}
catch (DataPortalException e) {
....
} }
I realize breaking changes are problematic.
At the same time, we'd become really sloppy about having more than 1 virtual method for a given set of related operations, thus requiring people to override multiple methods to ensure their code was actually executed.
In the case of a 'save' operation I think we were up to 3 methods you had to override to ensure your code would run during every save operation. That's just terrible if you think about it - the odds of someone forgetting 1-2 of those overrides was very high, and even if you did the overrides you'd be left dealing with writing your code so it could run behind sync and async calls. What a mess!
Resolving that obviously required a breaking change, for which I am sorry. But the benefits of the change are so compelling that (imo) they outweighed the cost of the breaking change.
Thank you for your explanation, I totally agree it is better to handle the Save in just 1 method!
Copyright (c) Marimer LLC