CODEWITHSUNDEEP
c#dependency-injectiondomain-driven-designservice-locator
Steve Wilkes
Steve Wilkes

Reputation: 7135

Domain Driven Design: access a configured value from an Entity without using a Service Locator

I have a User entity which has a HasCompletedSecurity property which indicates whether that particular User has answered the number of security questions required by the system. The number of security questions the system requires is configurable and retrieved from a config file. How should the User class access the configured information?

I currently have an IConfigurationService interface behind which I have implementations which use the ConfigurationManager or the Azure equivalent if it is available. I've encapsulated access to my DI container through a static InjectionService class, and am currently resolving the configured value like so:

public class User
{
    private static readonly IConfigurationService _configurationService = 
        InjectionService.Resolve<IConfigurationService>();

    public bool HasCompletedSecurity
    {
        get
        {
            // Uses the static _configurationService to get the 
            // configured value:
            int numberOfRequiredResponses = 
                GetConfiguredNumberOfRequiredResponses();

            return this.SecurityQuestionResponses.Count()
                >=
                GetConfiguredNumberOfRequiredResponses();
        }
    }
}

This is of course an example of the ServiceLocator anti-pattern, and I don't like it one bit. The static dependency makes unit testing anything which uses this class awkward.

I'm using the Entity Framework and taking a cue from here I don't want to pass my entities through a DI container to give them their dependencies, so... how should I be accessing the configured value instead?

Edit: With this exact example to one side (and I do appreciate the suggestions as to the correct architecture for it), the larger question I'm interested in is how do you manage non-static references to services from entities? Is the answer to just architect the entities in such a way that you never need to?

Upvotes: 7

Views: 545

Answers (2)

Pete
Pete

Reputation: 11495

You can still using the concept of Inversion of Control without using any sort IoC container or requiring its use in the constructor of your entity. I would approach this using a quasi-strategy pattern and have something like:

public interface ISecurityPolicy
{
    public int MinimumSecurityQuestionResponses { get; }
}

public class User
{
    public void HasCompletedSecurity (ISecurityPolicy security_policy)
    {
         return this.SecurityQuestionResponses.Count()
                     >= security_policy.MinimumSecurityQuestionResponses;
    }
}

This puts the onus of providing the particular security policy that the user must satisfy on the caller, not the User class itself.

From that point on, you can provide that extra parameter however you want to, maybe be wrapping this in a IUserSecurityService that will have the ISecurityPolicy injected into the service, etc.

This is still Inversion of Control, but it's at the method level, since this one particular method is really the only one that cares about the security policy/configuration.

Upvotes: 1

Mark Seemann
Mark Seemann

Reputation: 233150

Here's how I would define the User class:

public class User
{
    public bool HasCompletedSecurity { get; set; }

    // other members...
}

Seriously, this is a better solution because it decouples the value along the temporal dimension. Consider this: if a user completed all security questions in 2010 and you later on change the business rule, are you then going to invalidate the existing user?

In most cases it would probably be more reasonable to record and persist that sometime in the past, the user completed the security procedure that was in effect at that time. In that way, you don't bother existing users.

Upvotes: 5

Related Questions