我目前正在查看多个教程（和阅读书籍）以开始使用 ASP.NET MVC。
我看到ninject（或类似的）被广泛用于实现依赖注入，据我了解，这里的主要问题是我需要的类的资源分配。
例如，我们希望确保我们只有一个 repo 对象的实例。
我需要先学习第一件事，所以我有兴趣知道如何在不使用 DI 技术的情况下创建 ASP.NET MVC，并且就我的对象资源而言仍然是正确的
更多信息：
我做了一些winforms应用程序。这些应用程序使用业务层 DLL (BLL)。这个 BLL 可以访问我的 DAL DLL（纯 ADO.NET）。他们工作得很好..
不，我想对 MVC 应用程序使用相同的 BLL。
注射与否？
没有注入实现？
我是否只是在我的控制器构造函数中创建 BLL 对象，仅此而已？
ASP.NET MVC 根本不需要你使用依赖注入。如果您的所有控制器都有默认构造函数，它将完美地工作。另一方面，您将负责创建对象并管理它们的生命周期。如果您需要为应用程序拥有一个存储库对象，则必须手动实现其生命周期（使用静态变量或单例模式）。
如果您关心测试，使用依赖注入肯定会帮助您设计更多可测试和可重用的对象。您可以在测试代码中轻松地用测试替身替换依赖项，并让 DI 容器在运行时注入真正的实现。
如果您确定不使用它，请确保您的所有控制器都具有默认构造函数。您不需要任何配置。
使用 ASP.net MVC 不需要依赖注入。没有它你绝对可以构建一个 MVC 应用程序。
如果您想对应用程序执行单元测试，它将派上用场。如果您想对控制器中的操作进行单元测试，如果您设置了 DI，那么您可以模拟包含在控制器构造函数中的依赖项（DI 在应用程序运行时负责）并设置响应当它们被 Action 调用时返回。
如果您不使用依赖注入，这将更加困难和不切实际（如果不是不可能的话）。在这种情况下，如果您想使用单元测试，则很难为您的操作编写纯单元测试，因为您将没有简单的方法来模拟您的测试服务和数据访问层。
正如您所写，DI 层还将使您能够确保只有一个您要注入的存储库对象的实例等。