What is the right implementation of the Dependency Inversion Principle in C#?

Question

I'm building a password generator. I'm trying to apply the Dependency Inversion Principle (DIP) but so far my solution still seems to be coupled with concrete data.

How do I decouple the PasswordGenerator? So I don't have to pass to it

new PasswordRequirementsRepository(new PasswordRequirements{[properties assigned here]}) 

and I can inject an interface instead which will be used by IoC Container? How can I pass in the data assigned to PasswordRequirements properties to the PasswordGenerator without creating an instance of PasswordRequirementsRepository?

I'm struggling when passing different sets of password requirements because in PasswordGenerator I have to pass a concrete instance of PasswordRequirementsRepository instead of interface. I guess what I'm trying to achieve is to decouple PasswordGenerator from the concrete set of password requirements.

IPasswordRequirementsRepository.cs

public interface IPasswordRequirementsRepository
{
    PasswordRequirements GetPasswordRequirements();
}

PasswordRequirementsRepository.cs

public class PasswordRequirementsRepository : IPasswordRequirementsRepository
{
    private readonly PasswordRequirements _requirements;

    public PasswordRequirementsRepository(PasswordRequirements requirements)
    {
        _requirements = requirements;
    }

    public PasswordRequirements GetPasswordRequirements()
    {
        return _requirements;
    }
}

IPasswordGenerator.cs

public interface IPasswordGenerator
{
    string GeneratePassword();
}

PasswordGenerator.cs

public class PasswordGenerator : IPasswordGenerator
{

    private readonly IPasswordRequirementsRepository _repository;

    public PasswordGenerator(IPasswordRequirementsRepository repository)
    {
        _repository = repository;
    }

    public string GeneratePassword()
    {

      PasswordRequirements requirements = _repository.GetPasswordRequirements();

      [password generation logic here]

    }
}

PasswordRequirements.cs

public class PasswordRequirements
{
    public int MaxLength { get; set; }
    public int NoUpper { get; set; }
    public int NoLower { get; set; }
    public int NoNumeric { get; set; }
    public int NoSpecial { get; set; }
}

Answer 1

How do I decouple the PasswordGenerator? So I don't have to pass to it and I can inject an interface instead which will be used by IoC Container?

1st - Derive an interface:

public class IPasswordRequirements
{
  int MaxLength { get; }
  int NoUpper { get; }
  int NoLower { get; }
  int NoNumeric { get; }
  int NoSpecial { get; }
}

2nd - Inherit from interface:

public class PasswordRequirements : IPasswordRequirements
{
  public int MaxLength { get; set; }
  public int NoUpper { get; set; }
  public int NoLower { get; set; }
  public int NoNumeric { get; set; }
  public int NoSpecial { get; set; }
}

3rd - Update constructor:

public class PasswordGenerator : IPasswordGenerator
{
  public PasswordGenerator(IPasswordRequirements passwordRequirements)
  {
  }

That's it.

Don't use a repository here

My fear is that your understanding of a repository and DI infer some time of requirement to always be used together. What I believe your lacking is the code that instantiates dependencies. While a repository may at it's core provide that as a bases of it's pattern, it isn't the correct choice here, because of two reasons; first you aren't storing the items in the repository (that is there is no tier virtual or physical abstraction to wrap the repository around) and secondly you aren't providing generic access to a wide variety of types, just a single one.

At it's core the only thing a repository needs to be useful is a configuration/object to pass objects.. to some other tier (SQL, File system, Web API). A repository is not required in all instances to know anything about how objects are created.

Choose a framework that fits your need

Instead, what you need is a framework built at it's core around DI; object creation and disposal, and having an interface/configuration in which to configure the framework so it can be aware of dependencies to assist in the creation of dependent objects. There are three that come to mind AutoFac, Ninject and Unity. In each of these case, you are in some way, required to configure each type and use it's pattern to create objects. In many cases these Frameworks can even be full featured replacements with other Microsoft Frameworks (MVC for example, has it's own way to instantiate objects, but can be replace with other DI Frameworks). In no way are these frameworks required to know configuration on how to pass these objects to other tiers. It may do so simply by configuration as a by-product, but at it's core that's not what is configured.

For example with Autofac, first you create builder which is basically a fancy way to create a configuration:

var builder = new ContainerBuilder()

Then you register your types:

builder.RegisterType<PasswordRequirements>.As<IPasswordRequirements>();

Create a Container which manages objects: from their instantiation to their configuration.

var container = builder.Build();

Create a scope which defines the duration of an objects lifetime.

using (var scope = new BeginLifetimeScope())
{
  // all objects created by scope which be disposed when the scope is diposed.

  var passwordRequirements = scope.Resolve<IPasswordRequirements>();
}

By default passwordRequirements will be a new PasswordRequirements(). From there you simply build out your necessary dependency requirements and let the framework handle the rest.