Is dependency injection mandatory in asp.net MVC?

Question

I am currently reviewing several tutorials (and reading books) to get started with ASP.NET MVC.

I see that ninject (or the like) is widely used to inject dependency injection and from what I understand, the main problem here is allocating resources from the classes I need.

We want to be sure, for example, that we only have one instance of the repo object.

I need to learn the first things first, so I'm interested in learning how I create ASP.NET MVC without using DI methods and will still be correct as far as my object resources are concerned.

Additional Information:

I have made several winforms applications. These are applications that use the Business Layer DLL (BLL). This BLL had access to my DAL DLL (simple ADO.NET). they work quite well.

No, I want to use SAME BLL for MVC applications.

With an injection or not?

Without injection?

I just create a BLL object in my controller constructor and what is it?

Answer 1

ASP.NET MVC does not require you to use dependency injection at all. It will work just fine if all your controllers have default constructors. On the other hand, you will be responsible for the creation of facilities and the management of their service lives. If you need one repository object for an application, you must manually implement its life cycle (using a static variable or Singleton template).

If you care about testing, using dependency injection will certainly help you develop more testable and reusable objects. You can easily replace dependencies with test doubles in your test code and let the DI container insert real implementations at runtime.

If you are sure that you are not using it, make sure that all your controllers have default constructors. You do not need a configuration.

Answer 2

Dependency injection is not a requirement for using ASP.net MVC. You can create an MVC application without it.

Where it will be useful if you want to do unit testing in your application. If you want to perform a unit test action on the controller, if you have DI configured, you can make fun of your dependencies that are included in the controller’s constructor (which DI will take care of when the application is started) and configure the responses to return when they are called by the action.

This is much more complicated and impractical (if not impossible) if you are not using dependency injection. In this case, if you want to use Unit Testing, it will be very difficult to write clean unit tests of your actions, since you will not have an easy way to mock your access and data access layers for your tests.

And as you wrote, the DI layer will also allow you to provide things like having only one instance of the repository objects that you enter, etc.