CSharpTT

There are many posts out there which specifically say that we should not use service locator pattern (unless necessary), which we would not be able to determine the dependencies during compile time because the dependencies are hidden. However, I am going to point out an issue in case if you need to use it, in the context of ASP.NET Core projects. I have a class Foo , which will be bind to IFoo , and I will need to configure a named HttpClient for that class via the following extension,   services.AddHttpClient<IFoo, Foo>(); If we do the above, Foo will be treated as an object which is Singleton injected. In case you are not aware, we cannot inject services which has a smaller lifespan than the service itself. Hence, we cannot inject services which are transient or scoped into Foo . Here comes the problem, what should we do? That's where service locator pattern comes to the rescue! There might be other way, but let's say we decide to use the service locator provide...

One of the things that we can't escape while developing a system, is the use of database to store data. However, we ought to know that the frequency of database access will directly affect our system's performance. This is where caching comes in. Caching not only reduces the number of calls required to access the database, but also to increase the speed we could retrieve the data that we need. Cache is a storage pattern which allows for fast retrieval of data which we need frequently, and it should not be a set of data which changes constantly. In case of ASP.NET Core, there are 2 types of caching that we can use; in-memory cache & distributed cache . In-memory cache means that the cache is available for access within the application itself only. If we are building a system that contains multiple apps. which spread across multiple servers, each app. will have its own cache, which might be redundant, since all of them utilize the same data. This is where distributed cac...

There are often debates on whether to deploy ASP.NET applications in a single application pool, or assign a application pool for each application. In case of ASP.NET MVC with .NET Framework, the cons involved in the latter are: Each application pool has it's own memory pool, hence memory will deplete quickly, especially if you are hosting quite a number of applications in your server. It would difficult for you to perform updates on just a single application, especially if it requires you to turn off the application pool. #2 can be solved quite easily with the use of load balancer, since you could divert traffic to other server while you perform maintenance on the current server. However, there is no easy solution to #1 but to increase the memory of your server. Initially, I thought the same would apply to ASP.NET Core applications. However, we need to remember that IIS is just a reverse proxy in ASP.NET Core application, at least if you choose the out-of-process hosting...

During API development, we might often want to read the raw request body for logging or signature validation . In case of ASP.NET Core, we could use EnableRewind() to read the request body multiple times. using ( var reader = new StreamReader(Request.Body)) { var body = reader.ReadToEnd(); Request.Body.Seek(0, SeekOrigin.Begin); } However, if we are to use StreamReader  to read the request body, we will dispose the StreamReader using the using statement. This is a mistake if we are to read the request body in the future. Hence, we should use the following way instead. The following snippet is being taken from inside a Controller . // Read the request body, but do not dispose it var stream = new StreamReader(httpContextAccessor.HttpContext.Request.Body); stream.BaseStream.Position = 0; requestBody = await stream.ReadToEndAsync(); httpContextAccessor.HttpContext.Request.Body.Seek(0, SeekOrigin.Begin);

ASP.NET Core One of the more important aspect of API development is we have to give each request an identity. This is especially important if we are logging each request & response for tracing, caching, or validation. In case of ASP.NET Core, a request identity could be injected at the scoped level where it will lives through the life-cycle of a request. To bind the request data, we could use a middleware. Since the class is injected at the scoped level, each access to the class/object would be the same within the request life-cycle. A class to store the information of a request. public class RequestIdentity { public string ClientKey { get ; set ; } public RequestIdentity() {} public void BindRequestData( string clientKey) { ClientKey = clientKey; } } Using a middleware, we could easily bind the required information into the class. Let's assume the client key is supposedly being included in the header. public class RequestIdentityInit...