Change of Modifer in CSLA4.5

Change of Modifer in CSLA4.5

Old forum URL:

NET-H24 posted on Thursday, December 27, 2012


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.

JonnyBee replied on Thursday, December 27, 2012

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)

NET-H24 replied on Thursday, December 27, 2012

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?

JonnyBee replied on Friday, December 28, 2012

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.

Sander replied on Tuesday, September 16, 2014

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)










return await base.SaveAsync(forceUpdate,userState,isSync);




catch (DataPortalException e) {







RockfordLhotka replied on Friday, September 19, 2014

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.

Sander replied on Monday, October 20, 2014

Thank you for your explanation, I totally agree it is better to handle the Save in just 1 method!

Copyright (c) Marimer LLC