Dependency Injection with .NETCore for DAL and connection string

You could follow the options pattern with the configuration framework. This allows you to define a custom type that hold your configuration settings (statically typed) while being restricted to only your actual relevant configuration.

You can use it like this:

public void ConfigureServices(IServiceCollection services)
{
    // register the `Data:DefaultConnection` configuration section as
    // a configuration for the `DatabaseOptions` type
    services.Configure<DatabaseOptions>(Configuration.GetSection("Data:DefaultConnection"));

    // register your database repository
    // note that we don’t use a custom factory where we create the object ourselves
    services.AddScoped<IRepository<IDataModel>, BaseRepository>();
}

This assumes a type DatabaseOptions like this:

public class DatabaseOptions
{
    public string ConnectionString { get; set; }
}

Then, you can just have the DatabaseOptions injected into your BaseRepository:

public class BaseRepository
{
    private readonly DatabaseOptions _options;

    public BaseRepository(IOptions<DatabaseOptions> databaseOptions)
    {
         _options = databaseOptions.Value;
    }
}

Of course, if you have subtypes of that BaseRepository, you need to register those as well and pass the options to the base class:

// register the repository as well in the `ConfigureServices` method
services.AddScoped<PrivacyLevelRepository>();

public class PrivacyLevelRepository : BaseRepository, IRepository<PrivacyLevelDM>
{
    public PrivacyLevelRepository(IOptions<DatabaseOptions> databaseOptions)
        : base(databaseOptions)
    { }
}

---

I am instantiating and using the repo like I always have. I am not sure how to use a class that I don't instantiate. How do i let this object know it depends on the PrivacyLevelRepository?

PrivacyLevelRepository repo = new PrivacyLevelRepository();
returnValue = repo.GetAllByDomainID(DomainID).ToList();
return returnValue;

You do not appear to understand the idea behind dependency injection yet. Dependency injection with its underlying principle Inversion of Control is simply said about avoiding the use of new to create objects. Instead of actively depending on an implementation (in your example the PrivacyLevelRepository), you are giving up the responsibility and just depend on the outer system to provide you with the dependencies you need.

So instead of creating a new PrivacyLevelRepository, you inject an instance that is created by something somewhere else. That looses coupling on the implementation of your dependency. A very practical example of this is how PrivacyLevelRepository depends on IOptions<DatabaseOptions>. You, as a consumer of that repository, should not need to care to know how to get such an object to be able to create the repository instance. You shouldn’t even need to know how to create a repository instance in the first place.

So your consumer of PrivacyLevelRepository should follow the same idea as the repository itself: The repository does not know how to get those database options; it just depends on the constructing entity to pass such an object on. And your consumer, I assume a controller, should do the same:

public class MyController
{
    private readonly PrivacyLevelRepository _privacyLevelRepository;

    public MyController(PrivacyLevelRepository privacyLevelRepository)
    {
         // instead of *creating* a repository, we just expect to get one
         _privacyLevelRepository = privacyLevelRepository;
    }

    public IActionResult SomeRoute()
    {
         var domainId = "whatever";
         var data = _privacyLevelRepository.GetAllByDomainID(domainId).ToList();
         return View(data);
    }
}

Of course, something has to create the dependencies at some point. But if you embrace dependency injection completely—which ASP.NET Core not only makes very easy but also actively requires you to do so in order to work completely—then you don’t need to care about that part. You just register the types in the ConfigureServices method and then expect the dependencies to be fulfilled where you need them.

For more information, you should definitely check out the dependency injection chapter of the documentation.

As Steven mentioned, do not have your application components relying on IOptions<T>.

A more suitable way to access the connection string from the IConfigurationRoot though is done as follows:

string connectionString = configuration.GetConnectionString("DefaultConnection"); //substitute "DefaultConnection" for your named connection.

Where "DefaultConnection" is the object key of you connection string in appsettings.json

You shouldn't be injecting the IConfiguration at all into your classes. The IConfiguration allows access to all configuration values, while a class only requires one (or a few of them). Injecting the IConfiguration is the configuration equivalent of the Service Locator anti-pattern (but for resolving configuration values). It hides the actual used configuration values from the consumer and makes the class harder to use and test.

On top of that, this model makes it much harder to verify the correctness of your configuration file, since individual configuration values are only verified when they are requested for the first time in the application, which could be many mouse 'clicks' into the application.

The solution to this is to load and verify the configuration values at start-up and inject only the configuration value that one class requires, and nothing more. This allows the system to fail-fast and makes it very clear from the class's API what configuration value(s) it requires. Obviously, you could pack configuration values together into a single Value Object, and the newest .NET versions make this much simpler than it used to be, which is really nice.

Another thing you should prevent is using base classes. Base classes often become ever changing and growing blocks of code with helper methods and cross-cutting concerns. Their derivatives become much harder to test, because of the hard dependency on the base class.

When you inject the connection string directly into your PrivacyLevelRepository, there is no need to have a base class with a GetSQLConnectionString, since the repository already has the connection string available. There might be other reasons why you have this base class, for instance because you want to do logging or implement security features, but my advice is to not use base classes for this. Decoration and interception are more effective methods, because they allows to keep the class oblivious of these cross-cutting concerns and even allows a much more modular and flexible system.

UPDATE

This is the way to configure it

string conStr = config["Data:DefaultConnetion:ConnectionString"];

services.AddScoped<IRepository<IDataModel>>(c => new PrivacyLevelRepository(conStr));

I would also suggest preventing your application components from taking a dependency on the built-in IOptions<T> interface, since that has quite some unconvenient consequences, as described here.