ASP .NET Core Web Api 3.1 - komunikacja z Db

Hej uczę się pisaniem procedur w MSSQL oraz od razu próbuję to testować z wykorzystaniem. Mam kilka pytań z tym związanych

1.Czy obecnie dobrą drogą jest tworzenie takiej komunikacji z Db:

int count = 0;
            using (SqlConnection connection = new SqlConnection(_connectionString))
            {
                using(SqlCommand cmd = new SqlCommand("GetAllCarCount",connection))
                {
                    cmd.CommandType = CommandType.StoredProcedure;
                    connection.Open();
                    cmd.ExecuteNonQuery();

                  count = (int)cmd.Parameters["@RETURN_VALUE"].Value; //Jak pozyskać dane z procedury?

                }
            }

Czy może idzie się w stronę wykorzystania EF lub innych frameworków do komunikacji z bazą danych?

2. Mam problem, z odczytem wartości z procedury w API:
   Procedura :

USE [Db]
GO
/****** Object:  StoredProcedure [dbo].[GetAllCarCount] 
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER PROCEDURE [dbo].[GetAllCarCount]
AS
BEGIN
Select Count(Id) FROM Cars
END

I w sumie w web api próbuję "odczytać" wartość zwróconą z danej procedury za pomocą przykładu z punktu 1- ale niijak nie mogę jej pozyskać :/

3.W appsettings.json dodałem ConnectionString :

  "DefaultConnectionString": {
    "ConnectionString": "Server=(localdb)\\MSSQLLocalDB;Database=Db;Trusted_Connection=True;MultipleActiveResultSets=true"

  },

I próbuję w w api "odczytać go" w sposób:

 private readonly string _connectionString;

        public CarRepository(IConfiguration configuration)
        {
            _connectionString = configuration.GetConnectionString("ConnectionString");
        }

Ale zawsze __connectionString jest nullem :/

Z góry dzięki za pomoc i porady :)

Okej, z punktem 3 poradziłem sobie w następujący sposób:

public CarRepository(IConfiguration configuration)
        {
            _connectionString = configuration.GetValue<string>("DefaultConnectionString:ConnectionString");
        }

Wyciągnąć wyniki możesz z DataTable albo ustawiając ParameterDirection.Output i ręcznie rzutując. Rozwiązanie to miało swoich zwolenników, umieszczających w procedurach składowanych nawet logikę aplikacji, ale nie idź tą drogą za daleko.
Dobrze wiedzieć jak działa ADO, jednak do odczytu danych zamiast procedur zapewne lepszy byłby widok na bazie + np. Dapper po stronie C#.
Entity Framework przydaje się przede wszystkim do śledzenia zmian we właściwościach śledzonych obiektów i automatycznych insertów, update'ów itp. Zapytania też można nim robić, ale trzeba być świadomym ograniczeń interpretacji LINQ na SQL, lazy loadingu i problemu N+1.