Tagged articles - ASP.NET Core

Using in-memory DbContext is a great way to mock your actual DbContext in unit tests. You basically initialize the instance of your DbContext and seed some random data before you assert the result of your repository method. Now the problem occurs if you are mapping database view to an entity...read more

Caching data using Microsoft SQL Server may not be the most popular way of caching data because of the performance comparing to caching data to Redis, but it is maybe the most convenient way to keep your state of the application outside the process itself. Beside, if you are already using SQL Server database, you can just move the caching infrastructure to a separate schema inside the same database and keep using it until requirements are met for cache storage of better performance (like Redis for example). This makes infrastructure not so complex and less dependent, again until the requirements for something faster are met. ...read more

Swagger is a great way do describe your RESTful API. In ASP.NET it is pretty easy to wire up your OpenAPI documentation with your service facade with Swashbuckle NuGet package. In .NET 5, WebApi project template comes with already built in support for OpenAPI via Swashbuckle package and you can get it already setup in your pipeline and dependency injection with an easy tick in new WebApi project in Visual Studio. ...read more

Since the time of ADO in .NET one of the limitations was that one connection can execute single command at the time. Same limitation Entity Framework inherited and you can execute single command at the time per instance of your DbContext. Typical dependency injection lifetime of DbContext is scoped, which means you can execute one command at the time as the DbContext is instantiated per HTTP request in ASP.NET Core application. ...read more

It is not uncommon to have a requirement to access tables or views in different databases in the same query. In order to be able to do your joins on tables or views in different databases you need to do it in the same connection instance which is bound to DbContext, therefore this access as to be accomplished from the same DbContext instance. Let try to see what is the obstacle of doing tis with EF Core in a sample project which will access two databases in order to execute query and return records from the database...read more

Not so while ago I wrote an article on Seeding data with Entity Framework Core using migrations. This approach relies on EF Core migrations to ensure seeding of specific data is done only once using __EFMigrationsHistory table to track structural migrations as well as data seeding migrations. In large number of cases this approach works just fine and you do not need to do any adjustments or add any additional tables, just use migrations mechanism out of the box...read more

Basic authentication is not so popular authentication method nowadays. There is a valid reason for that and that is mainly the way credentials are used to authenticate to access the resources...read more

As much as it is important for testing the functionality of the application, data seeding can also be used to pre-load some values like lookups not only to development and test environment but also to populate these values in production as well. Seeding of data can be done in several ways and in this article I will go through two ways of seeding data. Both of them have their pros and cons and it is up to you to pick the way you want to have your data pre-seeded in your application database. ...read more

Having your REST API versioned is important for evolving of the service over time. Especially if your service is exposed t multiple 3rd party clients...read more

Shifting from traditional monolithic application architecture to micorservices can solve bunch of problems and issues monolith application application design approach introduces, but on the other hand it has it's own drawbacks, although number of drawbacks compared to number of problems it solves is a lot greater so it makes sense to take a path in process of moving from monolithic to micorservices. On of the steps to move to micorservices is to physically have your services running as individual processes. This also means that in case of REST API type of applications you will have multiple instances and each of these instances will have it's own endpoints and documentation for them...read more

.NET Core has done a great job by introducing interface for most of classes which makes them easy to write unit tests around them. However, there are a lot of classes that re commonly used which are not refactored in .NET Core...read more

It is obvious that no matter what is the size and complexity of your application, configuration values on your local development machine and the environment where the application is going to run will be different. To avoid any hard-coding and recompilation of your code, the most common practice is to store application and environment specific values to configuration files. Although ASP.NET Core provides great out of the box solution for having multiple configuration files depending on the environment (Use multiple environments in ASP.NET Core), there are still things that should not reside in the configuration files. ...read more

SignalR is number one choice for real-time communication between server and client. It implements several transports for communication between server and client...read more

Working with file system operations like creating or deleting files and directories if quite often part of applications flow. Both .NET and .NET Core come with great out of the box classes and methods to achieve this. These classes and methods are part of System.IO name space, but unfortunately both .NET and .NET Core implementations are the same and they use static classes and method to manipulate files and directories on the host file system. ...read more

Whether you are doing micro-services or mid-size monolith applications that do not have to be too distributed, there is a big chance that you will depend on some external HTTP service. Whether it is REST, SOAP or any other type of the response, your application flow depends on it's response. Sure using queues and event-based communication between services or components will definitely increase the resilience of the application and make more error-proof, it adds additional complexity to the whole solution and sometimes that can be an overhead depending on the application type or the infrastructure you might be limited with. ...read more