Dependency Injection with .NETCore for DAL and con

Question

I am new to the DI patterns with .NETCore, and I am having trouble getting my connection strings to my DAL.

I followed the advice given in this thread via the accepted answer, and subsequent comments.

This is my base class

public class BaseRepository : IRepository<IDataModel>
{
    private readonly IConfiguration config;

    public BaseRepository(IConfiguration config)
    {
        this.config = config;
    }

    public string GetSQLConnectionString()
    {
        return config["Data:DefaultConnetion:ConnectionString"];
    }

This is a snippet of a repository class inheriting the base class

public class PrivacyLevelRepository : BaseRepository, IRepository<PrivacyLevelDM>
{
    public PrivacyLevelRepository(IConfiguration config) : base(config) { }
    public void Add(PrivacyLevelDM dataModel)
    {
         ...
    }
}

This is in my startup.cs

public void ConfigureServices(IServiceCollection services)
    {
        // Add framework services.
        services.AddMvc();
        services.AddScoped<IRepository<IDataModel>>(c => new BaseRepository(Configuration));
    }

However, In my service layer, the instantiation of the repository class is still asking for the (IConfiguration config) to be passed as a parameter.

 PrivacyLevelRepository repo = new PrivacyLevelRepository();

How do I get the IConfiguration loaded directly to my DAL, without having to pass it from Controller > BLL > DAL. This seems extremely inefficient, and incorrect. As the DAL should be determining the connection for an object, not the controller or service layer. They should be agnostic of the datasource, no?

I figure this is something simple, that I am just not seeing within the DI/IoC paradigm, but I cannot figure it out.

Edit: I am not using Entity Framework, but a custom Data layer.

Thanx for any help.

Answer 1

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 .NET Core makes this much simpler, 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. Instead use decoration and interception, because it allows to keep the 'derived' 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));

Whatever you do, do not let your application components depend on IOptions<T>, since that has quite some bad consequences, as described here.

Answer 2

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.

Answer 3

Define a class with properties of your needs:

public class ConfHelper
{
   public string ConnString { get; set; }
}

Than in Startup.Configure Services you can do something like this to read your settings from Configuration:

services.AddSingleton(new ConfHelper() {ConnString = Configuration["ConnectionStrings:Default"]});

You can keep the ConnectionString as following in the appSettings.json

"ConnectionStrings": {
    "Default": "Persist Security Info=False;User ID=USER;Password=PASS;Initial Catalog=DBNAME;Data Source=localhost;"
}

You can than expect this object to be Injected in the constructor by the platform anywhere in your code.

public class HomeController : ControllerBase {
    private readonly ConfHelper _conf;
    public HomeController(ConfHelper conf) { _conf = conf; }
}

Besides calling services.AddSingleton you can also register services as Transient and Scoped as per your constraints.

Answer 4

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