title: .NET Core EF, when to avoid asynchronous database calls
body: <p>I'm currently in the process of writing a simple web application, which utilize a mssql database to store data. As it is right now, I try to setup my business logic layer and thus structure it in the best possible way.</p>
  
  <p>Currently, all of my calls are made with Linq and actually none of them are asynchronous. I'm fairly new to asynchronous programming, and are generally curious to know, for which queries I should use asynchronous calls. </p>
  
  <p>As far as I understand it makes sense to use asynchronous database calls, because it frees up memory on my main thread and doesn't block the UI. Also, asynchronous calls can be run concurrently, which means that more transactions can be done at the same time. </p>
  
  <p>However, consider that I add multiple entities asynchronously within my context, and use the <code>SaveChangesAsync()</code> method to conclude my context. Isn't it then redundant to have multiple <code>AddAsync()</code> methods in my context, because <code>SaveChangesAsync()</code> will run everything asynchronously anyway? </p>
  
  <p>Conclusively, from what I have read and seen, a lot of people prefer to use asynchronous database calls. That is, rather the rule than the exception. </p>
  
  <p>If so, in what cases would I avoid asynchronous database calls, what general rules should i adhere to when adding asynchronous calls in my business logic layer?</p>