Thinking and even recommending a monolithic architecture these days seems antiquated. While a microservices architecture clearly has its benefits, it also comes with drawbacks. Sometimes these drawbacks can be more significant than the benefits and might hinder your development, time-to-market, or your ability to maintain your application.
When people talk about WebAssembly and .NET Core these days, they immediately think about Blazor WebAssembly. But there is more to it. Actually, Blazor WebAssembly currently does not run our code as a WebAssembly (Wasm) module, but rather runs the .NET CLR (or a Mono version of it) as a Wasm module and our .NET code is run as plain old .NET assemblies on top of it. But there is indeed the need for executing (native) code as WebAssembly modules in the browser, and in .NET Core applications as well. In this article, I show how you can achieve running Wasm code in .NET Core, with a most likely future-proof approach.
It has been a while since I released my article about the usage of temp tables in Entity Framework (v6). Meanwhile, Microsoft has released a completely rewritten version of its O/R mapper so my old approach is no longer applicable. But before we learn about a new one, let us think about what we might need temp tables for.
Both a LINQ query and an SQL statement are descriptions that state which data should be fetched, but not how.. Sure, when reading LINQ or SQL, we can make assumptions about the performance but not in every case. Some queries are either too fancy or too big to grasp, so our predictions may be way too vague if we can make any at all.
After talking about performance issues like N+1 Queries and the Cartesian Explosion that made its comeback in Entity Framework Core 3, we will today look at a performance issue that is not tied to any Entity Framework version but is rather a general one.
First, the good news: In February 2020 Google is going to release Chrome 80. This release will include Google’s implementation of ‘Incrementally better Cookies’, which will make the web a more secure place and helps to ensure better privacy for users.
In my last article I explained how the changes in Chrome 80 (February 2020) can break your existing web sites or web applications, because SameSite cookies will be treated differently. In that post I focused on how to correctly set your cookies and how to mitigate incompatibilities between different browsers, as certain Safari versions don’t work correctly with the new way that Chrome enforces.
In the previous blog post we used a navigational property to work around the limitations of the extension method GroupBy. The problem is, there is not always such a property we can use for grouping. Especially, when following domain driven design practices, a bidirectional navigation is undesirable to not to pollute the domain model (too much). Besides not introducing a navigational property intentionally there might be use cases when we have to group data by property such as the name of a record. In this case there simply cannot be a navigational property.
With Entity Framework Core 3.0 (EF) the internal implementation of the LINQ query translation has been changed a lot. So, some queries that didn’t work previously are working now and some that worked are not working anymore. 🙂
The Entity Framework Core (EF) extension method Include provides us the ability to load additional data besides the entities we are querying for. For example: loading products along with their translations.
