Deep Dive into Many-to-Many: A Tour of EF Core 5.0 pt. 2

Jeremy Likness is a Cloud Developer Advocate for Azure at Microsoft. Jeremy has spent two decades building enterprise software with a focus on line of business web applications. He is the author of several highly acclaimed technical books including Designing Silverlight Business Applications and Programming the Windows Runtime by Example. He has given hundreds of technical presentations during his career. In his free time Jeremy likes to CrossFit, hike, and maintain a 100% plant-based diet.
Comments
Modern Entity Framework: A Tour of EF Core 5.0 pt 1
By convention; the `int id` parameter is matched to the `_id` field. If you omit the id field from the private constructor then EF Core will set the field directly. This is totally reasonable, but you’ll have to suppress compiler warnings that the field is never set.
Using Entity Framework Core with Azure SQL DB and Azure Cosmos DB
"Recommended" depends on your use case. The SDK is great; the most common use case is for teams already familiar with EF Core who want to take advantage of the conventions and API offered there.
To be fair, I contrived the example to show discriminators but in the "real world" the posts would be an "owned entity" of the blog and get stored as embedded values rather than separate documents. That is possible, just not the scenario that I showed.
Using Azure Container Registry for building and deploying .NET Core Apps
Blazor in the cloud: Hosting a C# SPA app as a static website in Azure Storage
Apply custom domain: https://docs.microsoft.com/azure/cdn/cdn-map-content-to-custom-domain?WT.mc_id=blazor-ch9-jeliknes
Add SSL: https://docs.microsoft.com/azure/cdn/cdn-custom-ssl?tabs=option-1-default-enable-https-with-a-cdn-managed-certificate&WT.mc_id=blazor-ch9-jeliknes
Azure Functions: Less-Server and More Code
@tartufella: that is a great point! I purposefully did not worry about concurrency in this case because it is my link shortener so I don't plan to be concurrent with myself, but absolutely something to think about in the bigger picture. However, concurrency is handled by the Table Storage in my understanding. When the NextId is loaded, there is a unique concurrency identifier in it (that's why we inherit from the TableEntity class) and this is sent back in the update operation. If the timestamp on the entity in storage has changed, it will throw an exception. So I don't believe you can actually end up with duplicate short URLs unless you explicitly disable the concurrency check. If you haven't already, great description in this doc: Managing Concurrency in Microsoft Azure Table Storage.