4

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?

3
  • 1
    Your class name MovieReviews should be MovieReview, since one object represents a single review, not many.
    – Doc Brown
    Feb 24, 2014 at 9:12
  • Easier unit testing is a DI "byproduct", not the main benefit of DI. Loose coupling is the main benefit of DI.
    – devnull
    Feb 24, 2014 at 9:22
  • I'd also remove the _str and _dt from your field names. They add nothing and just get in the way and make the code less readable.
    – Sam Holder
    Feb 25, 2014 at 8:31

2 Answers 2

6

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

1
  • The query/command objects pattern you are suggesting has been given a name and it's called CQRS. Greg Young is preparing a book about it as well as Event Sourcing.
    – Andy
    Sep 11, 2016 at 16:43
5

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.