I have a window that shows customer infomation.
when the window loads, I call LoadCustomer() method from the constructor which loads the customer information from the database asynchorously, which sets the CurrentCustomer property.
and then the UI is updated because it is bound to the CurrentCustomer.
private void LoadCustomer(Guid customerID)
{
var customerContext = new CustomerContext();
var customerQuery = customerContext.GetCustomersQuery()
.Where(e => e.CustomerID == customerID);
customerContext.Load(customerQuery,
loadOperation =>
{
CurrentCustomer = loadOperation.Entities.SingleOrDefault();
}, null);
}
The senior programmer has told me that it’s better to put this logic inside CurrentCustomer’s get accessor, because then
- the calls to the database will use lazy loading, and
- the refactoring would be easier.
Is it good practice to put async database calls inside property’s get accessor?
Generally, it’s not.
Usually if getting something would involves doing something else expensive as well, you should use a full getter method just for this purpose:
This signifies that getting that something isn’t free… Compare to:
This looks more like a normal value assignment hiding the dangerous async call going on behind the scene which, IMO is a bad idea.
But as with everything else… it depends on other parts in the whole architecture as well.
If the whole purpose of the object is to abstract away lots of asynchronous calls using property (such as the case with Linq2Sql or Entity Framework entities) then that’s fine because you must be aware that you’re dealing with calls that are not (or close to) free from the context of the code.
…
It depends on the context of the code. If whenever you are accessing this property, you are sure you’ll be reminded of the expensive call, then I think it is fine. But if that isn’t the case, then you should make it more explicit by turning it into a full-blown method instead of a property.