Posts

Showing posts from December, 2019

Single application pool vs multiple application pool [ASP.NET Core]

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

Working with request body in ASP.NET Core

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);

Usage of Expression to create generic query method for NHibernate

In my previous post about caching and generic query via NHibernate [ https://csharptipstricks.blogspot.com/2019/12/caching-and-generic-query-using.html ], there was a method that takes Expression as a parameter, as shown below: // Check if a record exists or not public async Task< bool > IsRecordExistsAsync<K>(Expression<Func<K, bool >> condition) where K : class { bool isExist = await GetSession().QueryOver<K>() .Where(condition) .RowCountAsync() > 0; return isExist; } Initially, I had the intention of creating a common method which could produce an Expression that holds a Func<K, bool> delegate. The method is as follow: public static Expression<Func<T, bool >> CreateCondition<T>(Func<T, bool > func) { return x => func(x); } When I use the Expression produced via the method above as an input parameter fo

The importance of request identity

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

Caching and generic query using NHibernate [.NET Core]

One of the important aspects in API design is to reduce the number of fetch request to database. NHibernate provides 2 levels of caching, with the first level cache persist through a session only, while the 2nd level cache persists across multiple sessions. The second level cache can be implemented by installing the NuGet package of NHibernate.Caches.SysCache . Then, it involves some configuration setup to utilize the cache feature. However, there is an alternative way that exists in .NET Core which we could use to build a simpler cache. The caching that we could use is IMemoryCache . Firstly, we could setup the cache during  ConfigureServices . public void ConfigureServices(IServiceCollection services) { services.AddMemoryCache(); } Then, assuming we want to retrieve all the records from a table called DailySales , and we want to keep the records in the cache for 1 minute, we could do the following. private readonly IMemoryCache cache; public DBHelper(IMemory