How to avoid pollution of logic with lazy-loaded async properties

Question

To be able to scale I would like to use async programming. It works really well if I have to read something from db and push to frontend, however I do not know how to use it correctly in blobs of buniess logic that live their own lives. I have object, that has lots of properties that should be lazy loaded. For instance Order class that has Recipient, Payer, DeliveryAddress etc. It groups services that read something based on orderId.

In old times I would do: Payer payer = order.Payer; - it would check request cache and query base as needed. However now I have Payer payer = await order.Payer() and I hate it. It forces all my logic code to be asynchronous (because in accounting software Payer needs to be everywhere).

How to solve this problem?

Answer 1

Don't make things lazy that don't need to be. If you know that Payer will be needed the grand majority of the time then there is no value in making the loading of Payer be lazy. Instead make it eager on constructions of Order.

Lazyness is only of value for expensive things that may not happen or don't need to happen.

---

As a side note when doing a lazy load of one property it could be of value to use that load to also fetch the other properties. Each of lazy load will have significant overhead. So if you are doing a request for one property you may as well get them all.

Answer 2

Lazy loading need not be asynchronous. A synchronous implementation could look like

Payer _Payer;
public Payer Payer
{
    get
    {
        if (_Payer == null)
        {
            _Payer = LoadPayer();
        }
        return _Payer;
    }
}

It might include lock and another check if _Payer is still null after the lock was acquired.

On the other hand, the async idea is meant to spread thru all your code: go async all the way, not just with a few functions. If you don't like that idea, go with non-asynchronous lazy initialization!

Answer 3

Just to add to Bernard's answer, the code for synchronous lazy loading can be made far simpler than what he shows:

private Payer _payer;
public Payer Payer => _payer ?? (_payer = LoadPayer());

Answer 4

A better way is to seperate the concerns eg the Data fetch and the logic.

eg

var data = fetchData();
var logic = new Logic(data);
logic.DoLogic();
var changes = logic.GetChanges();
await persistChanges(changes).

This works better in DDD / CQRS and is one of the reasons for those designs but if you DO have separation of concerns than logic should be sync and IO async.

Its the intermingling of data and logic while convenient for small apps tend to lead to a mess in bigger ones. Separation of concerns here fixes the async logic issue not to mention better testing.

"In old times I would do: Payer payer = order.Payer;" This is a perfect example of mixed concerns as you mention it fetches ( eg lazy loads) the payer. Payer here is a PayerEntity.