首先，我正在使用Simple Injector，但我认为这个问题适用于任何DI框架。
在创建要注册到应用程序的服务时，通过构造函数将服务容器传递到服务中是否被认为是不良实践？
例如。考虑以下代码：
//IServiceInterface.cs
interface IServiceInterface {}
//MyService.cs
//All standard using statements here...
using SimpleInjector;
class MyService : IServiceInterface
{
private _container {get; set;}
public MyService(Container container)
{
_container = container;
//Construct!
}
}
//MyApp.cs
public Contrainer container;
....
//My application bootstrapper method
void Bootstrap()
{
var container = new Container();
container.RegisterSingle<IServiceInterface >(() => new MyService(container));
container.Verify();
this.container = container;
}
如您从上面的方法中看到的，我定义了一个服务类，它需要接收一个Simple Injector容器。当我注册容器时，我将与我的应用相关联的容器传递给该服务。
这似乎是在定义将在单独项目中使用、甚至可能位于不同命名空间中的服务时很有用的方法，该服务将在应用程序生命周期的某个时刻需要注册新服务。然而，在我尝试这样做之前，我没有在任何示例中看到过这样做，因此我想要确保这种方法是正确的。
这种行为是否被认为是良好的 DI 实践？如果不是，那么如何获取应用程序的 DI 容器，并在服务内部需要注册新服务时进行注册？
更新--其他细节
我决定为一个新项目使用依赖注入，原因有二。其一，这是一个庞大的项目，可能包括 10-12 个 Visual Studio 项目；其二，这些项目中的许多代码都是多年来从一个应用程序复制和粘贴到另一个应用程序中，然后稍加修改而得到的。够了，是时候编写我们自己的业务逻辑框架，以使其符合我们公司的需求。
这个第一个大项目似乎是开始 DI 和我自己的框架的地方。为了逐层构建和测试该应用程序，我正在定义许多接口和“外壳”服务类。这样，我就可以只连接我的顶级应用程序��并在其所需的项目完成并链接到我的解决方案时更新依赖项。
由于这是如此庞大的应用程序，我有些服务需要依赖于其他服务...进而依赖于更多的服务。
我的想法是，我的应用程序只应注册用来验证用户和加载视图所需的服务。视图服务应注册模型视图。模型视图服务应注册它们关联的模型服务，后者将注册数据库连接服务... 呼哧，最终将注册一个服务器端同步服务，该服务将注册本地 DB 连接服务和 Web 应用程序服务。噢！听起来混乱吗？好吧，有点混乱。
我的想法是，我可以定义这些类，它们可以接受一个容器对象，然后每个服务将使用容器来获取可能已经存在的任何底层服务，如果还没有创建，则实例化一个新服务。
例如，我的用户认证服务可能通过一个ILocalDB服务缓存信息，应与我的模型服务共享。如果在启动应用程序时注册所有这些服务，应用程序将变得缓慢，而整个注册过程看起来会相当混乱。
我认为这必须有一个优雅的解决方案。我错过了什么？