title: Retrofitting Dependency Injection and Automated Testing: Factory and Load/List method confusion
body: <p>I am working on a new phase of an MVC project.  The first phase was fairly small and not very complex.  The next phase will be very complex and much bigger.  During the first phase we discussed and then discarded the idea of doing thorough automated testing for various reasons.</p>
  
  <p>With the new phase, I want our team to invest in automated testing.  I don't think we can do anything useful without dependency injection since we will want to stub out the database work to make our tests controllable.</p>
  
  <p>What I struggle with is retrofitting dependency injection into my business layer.  Our existing business objects have state, behavior, and are responsible for loading instances of themselves (via static methods).  For example, we might have this over-simplified example:</p>
  
  <pre><code>public class User
  {
      public User(string userName)
      {}
  
      public bool Authenticate()
      {}
  
      public static User GetByUserName(string userName)
      {
        //Do some DB querying, and then map the data object to a new instance:
        UserRepository repository = new UserRepository();
        var databaseObject = repository.list(u =&gt; u.userName = userName);
        User user = new User();
        user.userName = databaseObject.userName;
        // populate other fields
        return user;
      }
   }
  </code></pre>
  
  <p>From a quick glance, it seems I will need to:</p>
  
  <ol>
  <li>Inject the Repository as a dependency in the constructor</li>
  <li>Change the GetByUserName to no longer be a static method in User</li>
  <li>Do some sort of factory to be able to create an instance of User in the GetByUserName method</li>
  </ol>
  
  <p>I can't figure out how to do all of this in a reasonable manner.  #1 is trivial, but #2 and #3 are less trivial.  Here's what I'm thinking about how to do #2:</p>
  
  <ol>
  <li>Leave the structure largely as is and just remove the static keyword.  This means that in order to get a User by username you have to create an instance of the User object then call the GetByUserName method.  This does not pass my highly sophisticated smell test.</li>
  <li>Move the responsibility for loading and saving Users to some sort of UserCollection object.  This seems dubious to me because it means almost every business object would need an underlying collection object, and because it would make my domain model more anemic.</li>
  <li>Interface with the repository directly.  Right now the controller might call User.GetByUserName() to get a User domain object back to do some work.  Instead the controller would be aware of the repository and call Repository.list().  That seems leaky to me - suddenly the Controller feels like it's doing businessy things.</li>
  </ol>
  
  <p>Then there's #3.  It seems like my options are either to use my IOC container to inject factory methods (e.g. autofac factory delegate) or to manually create the factories for each object.  It seems leaky to use the autofac methodology because then I have to either use autofac in my unit tests or stub out a factory delegate for each object.  It seems troubling to make factories for all objects because at some point I'm imposing significant workload on developers just to be able to use DI without being aware of my IOC container.</p>
  
  <p>I've done what I can to search for these subjects but I'm really not seeing a lot of concrete examples that don't involve the drawbacks above.</p>
  
  <p>What are some techniques for solving #2 and #3 without losing "Good Design" or making "Too Much Work"?</p>