Blazor, BusinessBase and async

[mikeclimbs23]

I'm using blazor and async calls to load BizObjects. Should I be declaring fetch as async. The fetch in the book and project tracker isn't declared as async.

private async Task Fetch(SqlCommand cmd)
        {
            using (var dr = new SafeDataReader(await cmd.ExecuteReaderAsync()))
            {
                if (dr.Read())
                {
                    Fetch(dr);
                }
            }
        }

Thanks,

Mike

[rockfordlhotka]

CSLA supports both

[Fetch]
private void Fetch()

and

[Fetch]
private async Task FetchAsync()

You can use either, and the data portal will work as expected. So the real question is whether, inside your method, you need to call await or not.

[mikeclimbs23]

Thanks, as always very helpful.

Mike

[TheCakeMonster]

This doesn't directly answer the question you asked, but since I tripped over the information, I thought I'd add a bit more detail on this discussion, for completeness.

Blazor WebAssembly, accessing a data portal server using the HttpProxy, can only use async on the client. This isn't a limitation of Csla, but a limitation imposed on us by the runtime. HttpClient only supports async, and WebClient, which Csla uses under the covers to do synchronous HTTP calls, isn't implemented in the runtime used to host Blazor WebAssembly.

For this reason, I'd recommend making use of data portal's FetchAsync method in your Blazor UI code. That means it will work with either Blazor WebAssembly or Blazor Server, and you can change between them without issue (or use different hosting models in different sites using the same objects.)

This also reduces the risk of sync over async being introduced into your system without you being aware. Csla is capable of accepting a sync request via DataPortal.Fetch and running an async data access method, to help you out. However, if you are using LocalProxy - client and server methods running in the same process - then it has to do so by using sync over async. In some scenarios, sync over async will cause your system to deadlock. This is something you should avoid.

But wait, there's more. Things are made more exciting by Csla's FieldManager class, and how it interacts with child objects. FieldManager currently only exposes a sync UpdateChildren method, so if you write async code in any child objects, you almost always suffer sync over async. So there is a lot to answering how best to do your data access.

My general recommendations are as follows:

1. If you are going to need to use async/await in your data access method - either for better scalability or because it might call something that only offers async access to your data store - then you should also use async for the call into DataPortal on the client.
2. Currently, you should not use async data access methods for Insert, Update or Delete of child objects. There is an open issue to look at fixing this, because that's very limiting. Note that Create and Fetch are unaffected by this problem.

The world is going async. There are already some data storage providers that only offer async. When they go async only, they force everyone else to do the same. Therefore, what I do is design for async from the outset. Here are my rules:

1. All new client-side calls are built using async only. Only if your client code can't support async would I consider anything else.
2. If client-side calls need to be sync, then they should execute sync data access methods.
3. Assuming the client calls are async, then all of the data access methods in a root object would be async
4. Assuming all client calls are async, Create and Fetch data access methods are async in child objects, but Insert, Update and Delete are sync.

Once we've found time to address issue #2393 then the last rule will change so that all data access methods in child objects are async in that scenario.

[michaelcsikos]

@TheCakeMonster if the data for a child object has already been fetched by its parent and is passed in as a DTO to the child's Fetch method, do you still declare it async?

[rockfordlhotka]

There's probably no value in using async in that case. You've already retrieved the data, so it is in memory, and the child fetch operation is just going to copy the data from the DTO to the domain object's properties - all of which is a sync operation.

[TheCakeMonster]

@michaelcsikos Certainly there is no benefit in using the async keyword in the called method in your scenario. Therefore, as Rocky says, the strict answer to the question is that I wouldn't use async in the called method.

There is an option to allow for change by having it still return a Task; if you ever need to change it, it's a bit simpler to change if it's already being awaited by the caller. Having said that, you may never need to change it.

In my designs these days, I tend to go for a Task-based interface when there will be any data access involved now, or there may be in the future. The difference is really small if there is no (or only an implied) contract. The difference is bigger if there is an I_Something_ that defines a contract implemented by classes, because the interface would need to be changed in addition to the classes themselves, and that might also imply changes to tests and so on. If there is an interface, I would probably return Task and await it, rather than it being a void-returning method.

Within a data access method, as you describe, the likelihood of defining an interface is probably fairly small, and I would do the most efficient thing, which is probably a sync method (although in reality the difference in efficiency is likely to be nothing here, in most cases.)

I blogged about this a while ago for a friend. There is a difference between when I use await and when I use async. If you are interested in a deeper dive into the subject, the blog post is at https://blog.dotnotstandard.com/blog/design-for-async

[michaelcsikos]

Thanks @TheCakeMonster. I have embraced await/async since .NET 4.0, which usually meant having sync and async versions of all CSLA factory methods and commands. It looks like we're now at the point where we should leave out the sync versions altogether.

[TheCakeMonster]

For completeness, FieldManager.UpdateChildrenAsync was added to CSLA 6.0.

That means I need to update my recommendations listed above. My general recommendations are now as follows:

If you are going to need to use async/await in your data access method - either for better scalability or because it might call something that only offers async access to your data store - then you should also use async for the call into DataPortal on the client.

The world is going async. There are already some data storage providers that only offer async. When they go async only, they force everyone else to do the same. Therefore, what I do is design for async from the outset. Here are my rules:

1. All new client-side calls are built using async only. Only if your client code can't support async would I consider anything else.
2. If client-side calls need to be sync, then they should execute sync data access methods.
3. Assuming the client calls are async, then all of the data access methods in all objects (root and child) would be async methods.

Remember that the client calls I am referring to include saving the object. That means I prefer to use SaveAsync or SaveAndMergeAsync over Save or SaveAndMerge to fulfil the recommendation of "async all the way."

[rockfordlhotka]

Yes, WinForms and WPF (due to synchronization context) can have issues with a sync client and async server. This is because the callback from the server can't be handled by the client, because the client is blocked due to the sync call.

You can avoid this by doing async calls on the client - in both UI frameworks - but it is generally easier in WPF because a lot of WPF apps were built assuming async calls, so the UI patterns are generally friendlier to the idea. As @michaelcsikos points out, you can also do this in WinForms - it just wasn't a common UI pattern back in the mid-2000's, so few existing WinForms apps are built to accommodate the necessary UI implementation.

[Chicagoan2016]

@michaelcsikos Thank you so much. I am looking at the code and right now we have used BackgroundWorker components to load combo boxes but they don't work in not locking up the UI.
I am going to try your code.

1. We have already started changing Dataportal calls to DataPortal.FetchAsync, Should we change the ADO.NET to async or is it not necessary?
2. A stupid question :) , in your code what's on the left side of '='

   _ = TryLoadComboBox1Async();

Regards

[TheCakeMonster]

@Chicagoan2016 Yes, I would recommend updating the ADO.NET calls as well. The benefit of using async is mainly that you can use async calls to your data source. If you don't do this then there is probably benefit to using async methods (although I am guessing at your code a bit.)

A call to a data source is often slow, because it's across a network and/or may involve file access - directly, or under the covers. Making slow calls async frees up the thread which otherwise would sit idle waiting for I/O. In other words, you get more scale out of the same resources.

Calls out of process (on the same machine) are often an order of magnitude slower than calls within the same process. Calls across a network can be two orders of magnitude slower - sometimes more. It's the fact that they can be so slow that brings about the potential benefit of awaiting the results - many other tasks can be completed by the thread in that time in which it otherwise sits idle.

The underscore character on the left is used to discard the value from the expression on the right. It's a bit like making the call without any assignment at all, but it's making it clear in the code that you are intentionally discarding it - that it's not a mistake.

[Chicagoan2016]

Gentlemen, I don't have good news :)
Now the form just takes longer to load! Previously (with BackgroundWorker components) when I would click the button, the form would show up but the UI would be locked for four seconds.
After integrating @michaelcsikos ' code, I click the button, the form doesn't show up for four seconds but when it shows up, it's not locked.
So the 'wait' time doesn't change.
suggestions, please?

Kind Regards

[michaelcsikos]

@Chicagoan2016 Are your ComboBox data source loads async? If not, then it will block on the UI thread. If they are async and you're not awaiting the loading of the data sources there should be no delay in the form opening.

If the data sources are fetched with CSLA then you can simply convert to the appropriate async operation. If it's not CSLA, you can wrap a sync operation in a Task to run it async:

WidgetList list;

await Task.Run(() =>
{
    list = WidgetList.GetList();
});

cbo1.SuspendBindingsAndSetDataSource(list);