How to read ASP.NET Core MVC’s appsettings.json file into Data Access Layer

In this blog, I’m going to explain how to read a database connection string from ASP.NET Core MVC app’s appsettings.json file into the DataAccessLayer, which is a class library project. The DataAccessLayer is using EF Core Code-First approach. And, I have been using ASP.NET Core 3.1 for this blog.

Here is the simple layered architecture of my demo solution.

Solution Explorer

I added a SQL Server database connection string into appsettings.json file into MVC app. Take a look at the below image.

We need to install following two Nuget packages into DataAccessLayer in order to read appsettings.json file:

Microsoft.Extensions.Configuration

Microsoft.Extensions.Configuration.Json

Once done, we need to write following code into the OnConfiguring method of the class, which has been derived from the DBContext class. Have a look at below image.

That’s it! Run and see that DAL is able to read appsettings.json file from ASP.NET Core MVC app.

Online SQL Server T-SQL Programming training at Kantar Analytics, Bangalore | 24 Jun – 02 Jul, 2020

Due to COVID restriction, just conducted online sessions on SQL Server 2019 T-SQL Programming for around 25 novice professionals at Kantar Analytics, Bangalore.

Great experience conducting online session and lots of learnings to make it better!

Online SQL Server T-SQL Programming training at Kantar Analytics, Bangalore | 23 – 30 Sep, 2020

Conducted online sessions on SQL Server 2019 T-SQL Programming for around 20 experienced professionals at Kantar Analytics, Bangalore.

It was half-day training session for us. We learnt a lot of advanced concepts such as Indexes, Query Optimizations, etc. in T-SQL programming. Good experience overall!

Projects in Azure DevOps

Today I’m going to talk about the Projects in Azure DevOps.

Most of the time, we think that an Azure DevOps Project is similar to a Solution in the Visual Studio. We usually associate the Visual Studio’s Solution with the DevOps Project. But, in reality, we don’t associate a Visual Studio Solution with the DevOps Project. We associate a Visual Studio Solution with the Repos in the DevOps Project. If we carefully observe then we find that a DevOps Project may have more than one Repos. And, every Repos point to a Solution in the Visual Studio.

Hence, an Azure DevOps Project may have more than one Repos and, in turn, more than one Visual Studio Solution associated with it. Therefore, we can say that DevOps Project is a container, which may have more than one Solution.

We can conclude that an Azure DevOps Project is not similar to a Solution in the Visual Studio. It’s a bigger container, having more than one Solution.

Team vs Group in Azure DevOps

Very confusing? Yes! It’s very confusing to understand what’s the difference between Team and Group in the Azure DevOps. Let’s discuss about it today.

Both Team and Group are same. But they are different in the context i.e. the way and where we implement them. Both are part of a project in Azure DevOps. What I mean to say is we create or have a team or a group at project level, and not at the Organization level. Both are used to implement permissions to the human resources working on the project.

There are built-in groups i.e. Project Administrators, Build Administrators, Contributors, Project Valid Users and Readers. There groups are already provided by the Azure DevOps and can’t be deleted.

When we create a project, a team is created with the same name as project by default. And this team will appear if we go to the Permissions option in Project Settings where built-in permissions groups appear. This default team can’t be deleted too.

So, what the difference between a team and a group?

Both are used to implement permissions to the human resources. Let’s say, we have a project team with 20-25 people i.e. a small team working on the project. In this case, we don’t need extensive permission mechanism. So, we can go and add the users to the built-in groups one by one, and permissions will be implemented to them. Handling of a small group of resources is easier i.e. we can add or remove or delete them one by one. In this scenario, we don’t need a team concept. The built-in groups are suffice to implement the security/permissions.

But, let’s assume we have a team of 1000 resources working on a project. The Dev Team consists of 700 developers with various roles such as Sr. Software Engineer, Software Engineer, etc. When we need to implement permission for these 700 developers, it’s not wise practically to add/remove each user one by one. It would always be easier to have a group of 700 developers and implement permissions to the group or add that group to built-in groups. In this case we create the concept of a Team, add all 700 developers to a team and use that team as a Group. In fact, every team is technically a group.

Therefore, decision to have team/group depends upon what team size and architecture we have for the project. Based on that, we can decided either to work with only built-in groups or have both teams and groups. I recommend to start with built-in groups with simple architecture/permission mechanism and extend it later with teams if required.