Help With Dependency Injection

Question

I am still very confused as to why and when to use Dependency Injection. If anyone could explain maybe using the below example that would be great, any other explanations would be appreciated.

Lets say I am creating a web-app that will save movie reviews written in C# with ASP.NET MVC 5. If I have the following Model code,

namespace MovieReviewProject.Models
    {
     public class MovieReviews
      {
        [Key]
        public int ReviewID_int{ get; set; }

        /// <summary>
        /// Submitter email address
        /// </summary>
        public string EmailAddress_str{ get; set; }

        /// <summary>
        /// Movie name
        /// </summary>
        public string MoveName_str{ get; set; }

        /// <summary>
        /// The review
        /// </summary>
        public string Review_str { get; set; }

        /// <summary>
        /// The submission date from
        /// </summary>
        public DateTime SubmissionDate_dt { get; set; }

        /// <summary>
        /// The movie rating
        /// </summary>
        public int Rating_int { get; set; }
    }
}

how would a class that provides the Controller with the List of all the reviews, adds an average for a movie, and more look like?

I know that DI is mostly used to allow for easier unit testing but other than that what are the perks to it? Is it worth going through old projects and make sure all the providers are using this principal?

Answer 1

Whilst Doc Browns answer is a perfectly valid approach and will solve your problem, I would strongly suggest that you investigate using an approach that uses Command and Query objects rather than using the repository pattern.

The repository pattern suffers from issues around changes as every time you need a different query you have to add a new method to your repository interface, where as having Command and Query objects as first class citizens in your project means you can just add a new class when you need a new query and you don't have to change any exist code. It also means that when you want to apply cross cutting concerns (like logging) to your queries/commands then you can do it in a single place and wrap your command/queries in the logging wrapper.

You could implement it along these lines:

You could have a query class like:

public class GetAllMovieReviewsQuery : IQuery<IEnumerable<MovieReview>>
{
     public GetAllMoveReviewsQuery(int movieId)
     {
          MovieId = movieId;
     }

     public int MovieId{get;private set;}
}

This is simple and just collects the parameters it needs through its constructor, and declares the type of the return value of the query.

And then a handler for that query which actually queries the db:

public class GetAllMovieReviesQueryHandler : IQueryHandler<GetAllMoveReviewsQuery, IEnumerable<MovieReview>>
{
      private DbContext movieDbContext;

      public GetAllMovieReviesQueryHandler(DbContext movieDbContext)
      { 
           this.movieDbContext = movieDbContext;
      }

      public IEnumerable<MovieReview> Execute(GetAllMoveReviewsQuery query)
      {
           return dbContext.MovieReviews.Where(x=>x.MovieId == query.MovieId).ToList();
      }
}

then in your controller you inject an object which knows how to find the handler for any given query/command (basically a dictionary of the type of a query/command to the handler instance for that query command) and just call this

  class MyReviewController
  {
       public MyReviewController(IQueryDispatcher dispatcher)
       {
       }

       public IEnumerable<MovieReview> GetReviewsFromMovie(int movieId)
       {
            var query = new GetAllMovieReviewsQuery(movieId);
            return dispatcher.Execute(query);
       }
  }

This also has the advantage that you can have different sources for individual queries, by simply replacing the handler which handles that query with one that looks up the answer in a web service or whatever.

To then unit test this you could simply replace the IQueryDispatcher in the controller with a mocked instance which returns the values to test with when given a particular query.

This is an excellent place to start reading and also covers a fair bit about DI, but there are others who also think that the repository pattern has had its day and is more trouble than its worth

Answer 2

For such a requirement, you can use a MovieReviewsRepository class with an interface IMovieReviewsRepository:

 interface IMovieReviewsRepository
 {
      IEnumerable<MovieReview> GetAllReviews(int movieID);
 }

In your controller, you can inject an IMovieReviewsRepository object through the constructor:

 class MyReviewController
 {
       public MyReviewController(IMovieReviewsRepository repository)
       {
       }
 }

Now you are free to implement the interface by a class MovieReviewsRepository providing the objects from a database, or by a class MovieReviewsRepositoryMock providing, for example, some hardcoded test data without any database access. This will make real unit testing possible. But it will also allow to exchange the source of your "movie review objects" to something completely different like a web service or a file without changing the controller, just by providing different IMovieReviewsRepository implementations

Of course, this approach could be generalized to lots of your model classes by making your repository a generic class, like it is shown here.