标签：#asynchronous

Rule of thumb If your action waits on something external , make it async . If it’s instant CPU , keep it sync ; for expensive CPU , offload . The core idea Async shines for I/O-bound work (DB calls, HTTP calls, queues, files). It frees the request thread while waiting, so the server can serve more requests with the same thread pool . Sync is fine for trivial, short CPU work (formatting, small calculations) where you’re not awaiting anything and the handler returns in a few milliseconds. When to choose async You call EF Core ( SaveChangesAsync , ToListAsync ), HttpClient , Azure SDK ( ServiceBusClient , BlobClient ), file I/O, or any API with Async methods. You expect latency from a dependency (tens–hundreds of ms). You need cancellation and timeouts (propagate HttpContext.RequestAborted ). When sync is acceptable The action is pure CPU and trivial (e.g., quick math, mapping, input validation) and returns immediately. There are no I/O waits and no benefit from freeing the thread. If it’s CPU-heavy (image processing, big JSON transforms), do not just make it async—offload to a background queue/worker or a separate compute service. Async won’t make CPU faster. Pitfalls to avoid Don’t block async : never use .Result / .Wait() on Tasks (deadlocks/thread-pool starvation). Async all the way down : if the controller is async, downstream calls should be too. Don’t fake async : returning Task.Run around synchronous I/O just burns threads. Keep concurrency bounded when fanning out to multiple I/O calls. Mini decision checklist Any I/O? → Use async (end-to-end). Pure CPU? Tiny (≤ a few ms) → Sync is fine. Heavy/variable → Offload to background worker; controller returns 202/Location or uses a queue. ASP.NET Core examples Async (I/O-bound) — recommended [ ApiController ] [ Route ( "orders" )] public class OrdersController : ControllerBase { private readonly OrdersDbContext _db ; private readonly HttpClient _http ; public OrdersController ( OrdersDbContext db , IHttpClientFactory

With the Reactive Data Layer Architecture (RDLA), you establish a clear boundary between public data APIs and private, framework-specific data-source implementations. Your presentation layer operates in a purely reactive manner, observing data changes rather than procedurally querying them. RDLA also simplifies testing by encouraging you to program to interfaces and use clean seeding patterns. By Mervyn Anthony