4 ms·

Honest question, what does stop you from simply not using DI in .NET?

by elboru 6y ago

shireboy 6y ago
This was going to be my question. For your own classes and services, nothing is stopping you. You can new up classes without DI all day long. ASP.NET does layer on it's things using DI, but it's boilerplate built into templates. For example, OOB you may use the built in UserManager to authenticate users and store their info in a db. If you want to customize that and NOT use the built-in, you may have 10-20 lines to write in Startup.cs to inject a different UserManager or configure the built-in one differently. I've never felt it was massive or wasted my time vs Node/express work I've done.
mandeepj 6y ago
“ what does stop you from simply not using DI in .NET?” Duh! Then how’d you wire up interfaces with implementation aka constructor injection?
- acupofnope 6y ago
  Like so: `ISomething something = new Something();` Construction injection is a type of DI, and it's optional, you don't have to use it. edit: for clarity
  - mandeepj 6y ago
    OMG! I was wondering you might be proposing this. You should not be using "new" keyword anywhere in your code. If you have hard coded implementations like that in your code then how will you mock them in unit tests? I hope you'll not reply-with saying "don't write unit tests".
    - Thiez 6y ago
      I am a big fan of DI, but you can often get a lot of useful unit testing done when you try and keep I/O mostly seperate from the rest of the code. If you have ever programmed in Haskell you will know what I mean.
    - acupofnope 6y ago
      "OMG! I was wondering you might be proposing this. You should not be using "new" keyword anywhere in your code" That sounds like dogmatism, and I'm going to take a special note of the emotionally charged language you're using here; it's symptom of some of the underlying issues I see in our industry (more to be said on this). That said, I do agree with the sentiment in general, but you can (and sometimes should) use the `new` keyword in your code, especially when writing tests. In some cases, it makes testing so much easier and helps with the maintainability. "I hope you'll not reply-with saying "don't write unit tests" After 2 decades in this profession, the only think I'm sure of is there is no "silver bullet". Of course, as a general rule, it's a good idea to have a test coverage of your codebase but sometimes it's not valuable and not worth adding it. So it's a "it depends" from me!
decafninja 6y ago
Because if you don't tow the line, you'd be accused of heresy and blasphemy from the community and/or coworkers - I'm only partially joking.
- lodi 6y ago
  "toe the line"

Honest question, what does stop you from simply not using DI in .NET?

by elboru 6y ago

Honest question, what does stop you from simply not using DI in .NET?

This was going to be my question. For your own classes and services, nothing is stopping you. You can new up classes without DI all day long. ASP.NET does layer on it's things using DI, but it's boilerplate built into templates. For example, OOB you may use the built in UserManager to authenticate users and store their info in a db. If you want to customize that and NOT use the built-in, you may have 10-20 lines to write in Startup.cs to inject a different UserManager or configure the built-in one differently. I've never felt it was massive or wasted my time vs Node/express work I've done.

mandeepj 6y ago

“ what does stop you from simply not using DI in .NET?” Duh! Then how’d you wire up interfaces with implementation aka constructor injection?

acupofnope 6y ago
Like so: `ISomething something = new Something();` Construction injection is a type of DI, and it's optional, you don't have to use it. edit: for clarity
- mandeepj 6y ago
  OMG! I was wondering you might be proposing this. You should not be using "new" keyword anywhere in your code. If you have hard coded implementations like that in your code then how will you mock them in unit tests? I hope you'll not reply-with saying "don't write unit tests".
  - Thiez 6y ago
    I am a big fan of DI, but you can often get a lot of useful unit testing done when you try and keep I/O mostly seperate from the rest of the code. If you have ever programmed in Haskell you will know what I mean.
  - acupofnope 6y ago
    "OMG! I was wondering you might be proposing this. You should not be using "new" keyword anywhere in your code" That sounds like dogmatism, and I'm going to take a special note of the emotionally charged language you're using here; it's symptom of some of the underlying issues I see in our industry (more to be said on this). That said, I do agree with the sentiment in general, but you can (and sometimes should) use the `new` keyword in your code, especially when writing tests. In some cases, it makes testing so much easier and helps with the maintainability. "I hope you'll not reply-with saying "don't write unit tests" After 2 decades in this profession, the only think I'm sure of is there is no "silver bullet". Of course, as a general rule, it's a good idea to have a test coverage of your codebase but sometimes it's not valuable and not worth adding it. So it's a "it depends" from me!

decafninja 6y ago

Because if you don't tow the line, you'd be accused of heresy and blasphemy from the community and/or coworkers - I'm only partially joking.

lodi 6y ago
"toe the line"