Wei's Blog

Recently our development team attempted migrating our software architecture to microservices architecture. Despite being the most popular pattern mentioned everywhere, our journey came to the end with a surprising result, that was the team eventually decided to cancel the migration. After one developer from our team wrote a post to share our experience, I also want to share some of my personal opinions about microservices, a term, architecture, or pattern that was so controversial in the team in the last couple months. Engaging microservices The first time the term attracted me was when I saw a post about doing microservices on top of Azure Service Fabric. I absolutely loved the idea of splitting a monolith service into several stateless and stateful services, each of which could be deployed and maintained separately. Shortly after Azure had its Kubernetes and docker hub, I was also amazed how easy it was to build a containerized ASP.Net Core application and deploy it as a microse...

This time let's talk about Autofac, probably one of the most popular Dependency Injection container. In the past few months, I have been working on a project in which Autofac is used to provide service instances. In some of the singleton services, I needed to access some request scoped services, so I built a fun type called IScoped<T> to be able to use per HTTP request lifetime to resolve service types. And it works. However, today, when I was building a service in which I needed a list of IScoped<T> , I ran into a problem. One of the cool features that Autofac provides is implicit support for resolving IEnumerable<T> . Say if we register two implementation types as the same interface type, we could resolve an instance of IEnumerable of the interface type to retrieve all instances of both implementations types in one go. That's very cool, isn't it? However, it doesn't work as what I expect when resolving a list of IScoped<T> , where T has mu...

So this is the first post in the blog and the topic is interesting. A couple days ago, I did a code review for one of our developers, where I made a comment regarding how tasks are scheduled in ASP.Net applications (not ASP.Net Core). I was saying in the code review that no multiple tasks can run in parallel because of the special AspNetSynchronizationContext . Today I was asked the same question by another developer and later figured out I was not 100% correct. So I decided to spend sometime digging a bit deeper into the magic synchronization context and post what I have found. So the source code of the synchronization context could be found here . For those who are not familiar with synchronization context, I would recommend you read this stackoverflow post before continue reading the rest of the content. To make some tests, I wrote a very simple synchronization context class which schedules tasks using the same way as how AspNetSynchronizationContext schedules tasks: So sim...