DEV Community

Cover image for Episode 005 - Dependency Injection - ASP.NET Core: From 0 to overkill

Episode 005 - Dependency Injection - ASP.NET Core: From 0 to overkill

João Antunes on November 04, 2018

In this post/video we continue our look into base concepts of ASP.NET Core, in preparation to what’s in our way for building the application. This ...
Collapse
 
chenge profile image
chenge

DI is just a parameter of method, why so complicated?

Collapse
 
joaofbantunes profile image
João Antunes • Edited

You're right, DI is really a simple concept.

I can't speak from experience, as I never built such a framework, but I would say the complexity comes from building (potentially complex) objects graphs automatically at runtime, given the configuration we provide.

In C# (and for what I've seen of Java) the solutions are very similar to this. Other languages have probably different approaches, maybe they're simpler, can't really say.

Collapse
 
chenge profile image
chenge

I had ever done java and c# projects and know a little DI like spring. Later I select Ruby, when I do rails project I find I need DI to mock test, but no need for DI framework.

Maybe big project need a complicated DI framework like Spring.

Thread Thread
 
joaofbantunes profile image
João Antunes

Yeah, didn't do anything with Ruby myself, so can't make a good comparison.

Maybe we're lucky and there's another DEV member reading this that has experience in both and wants to chime in 🙂.

Thread Thread
 
chenge profile image
chenge

Welcome, happy to talk DI with you. I have the short ruby code to demo:

    class Factory  
      attr_accessor :product  
      def produce  
        @product.new  
      end  
    end  
    class Product  
      #..  
    end  
    fac = Factory.new  
    fac.product = Product  
    fac.produce  
Thread Thread
 
joaofbantunes profile image
João Antunes

Ah, I see, you create a factory and then use it instead of creating the Product directly.

In C# we normally use the dependency injection container as the factory (we still use factories on occasion, but for different reasons).

Using the container as the factory, and it being tightly integrated into the web framework, in the controllers, like you can see above, we just add the dependencies we want in the constructor, and the framework passes them in automatically.

public class GroupsController : Controller
{
    private readonly IGroupsService _groupsService;

    public GroupsController(IGroupsService groupsService)
    {
        _groupsService = groupsService;
    }

    //...
}
Thread Thread
 
chenge profile image
chenge
class PlayController < Controller

  def create(params)
     store = Invoice
     Invoice.generate_invoice(params, store)
     ... 
  end
end


In Ruby code is like this. Don't need a DI container.

Thread Thread
 
joaofbantunes profile image
João Antunes

Yupe. Different ways to get to the same end result of decoupling components 🙂

I like the C# approach, probably because I'm used to it, but I can understand that coming from other languages it seems overly complex.

Being able to just declare the dependencies in the constructor and they'll be there when running is nice (even if a bit magic) and gives quick visibility on the dependencies of a given class just by looking at the constructor. It does come with the hidden complexity you talked about, so as always, there are trade offs.

Collapse
 
dyagzy profile image
dyagzy

Many thanks for this chapter, see questions below:

  1. How do I when to use a 3rd party DI or IoC in my project

  2. Why did you use an extension method for ToViewModel and ToServiceModel? Although it seems a little confusing to me but I will go over it again till am able to understand it's use case.

  3. Which other way can be use to achieve the use of the extension method as you have done without using an extension method?

Thank you for your reply always.

Collapse
 
joaofbantunes profile image
João Antunes

Hi there!
Let's see if I can answer all of them:

  1. If the built-in container is good enough for your needs, probably just stick with it. Otherwise, you can look at alternatives if:
    • You already have experience and like a different container
    • You need some features that another container provides (including performance)
  2. These extension methods are just to move the boilerplate mapping code out of the controller. I could just have mapped everything in there, but the controller code would be polluted with things that are not really relevant for its logic.
  3. Not sure I understand this one. An extension method is a normal static method, with syntactic sugar to make things more readable, so instead of doing GroupMappings.ToViewModel(group), we can do group.ToViewModel(). Was this the question, or another thing?
Collapse
 
dyagzy profile image
dyagzy

Thank you for your responses.
I quite understand your answers to my questions (1 and 2).

I guess I should follow up with your tutorial to the next episode perhaps I will better understand your answer to the 3rd question.

I will revert back to you with more questions.