Which is the better way to carry request data(Is there any difference between two way)?
For example:
Option 1(Scoped Service
):
//Scoped Service(this may be interface)
public class SampleScopedService
{
public string Data { get; set; }
}
//Register service
services.AddScoped<SampleScopedService>();
//Set and Get Data
public class SampleUsage
{
private readonly SampleScopedService _sampleScopedService;
public SampleUsage(SampleScopedService sampleScopedService)
{
_sampleScopedService = sampleScopedService;
// _sampleScopedService.Data = "Sample";
// _sampleScopedService.Data
}
}
Option 2(HttpContext.Items
)
//Scoped Service
public class SampleScopedService
{
private readonly IHttpContextAccessor _accessor;
public SampleScopedService(IHttpContextAccessor accessor)
{
_accessor = accessor;
}
public string GetData()
{
return (string)_accessor.HttpContext.Items["Data"];
}
}
//Register service
services.AddScoped<SampleScopedService>();
//Set Data
HttpContext.Items[“Data”] = ”Sample”;
//Get Data
public class SampleUsage
{
private readonly SampleScopedService _sampleScopedService;
public SampleUsage(SampleScopedService sampleScopedService)
{
_sampleScopedService = sampleScopedService;
//_sampleScopedService.GetData();
}
}
Similarly, you use HTTPContext Items collection when you are sharing the same information across the different instance based on the user request and that request could be changed for a different request.
An HttpContext object will encapsulate specific details of a single HTTP request. Properties of this class include the Request object, the Response object, the Session object, and an AllErrors property which keeps an array of Exception objects accrued during the current request.
HttpContext isn't thread-safe. Reading or writing properties of the HttpContext outside of processing a request can result in a NullReferenceException.
Scoped services service is the better option when you want to maintain state within a request. Singletons are created only once and not destroyed until the end of the Application. Any memory leaks in these services will build up over time.
According to docs:
Avoid storing data and configuration directly in DI. For example, a user’s shopping cart shouldn’t typically be added to the services container. Configuration should use the Options Model. Similarly, avoid “data holder” objects that only exist to allow access to some other object. It’s better to request the actual item needed via DI, if possible.
Since Options 1 is example of “data holder”, as far as possible we should avoid it.
Furthermore, Options 1 may cause Captive Dependency if you don't pay attention.
So using Option 2 with singleton lifetime is better way than using Option 1.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With