希望这个问题不是太愚蠢，我试图掌握更高级的编程原则，因此试图习惯使用Ninject进行依赖注入。
所以，我的模型分为几个不同的.dll项目。一个项目定义了模型规范（Interfaces），其他一些项目实现了这些接口。所有模型项目都需要使用某种数据库系统，因此它们都需要访问另一个实现我所有数据库逻辑的.dll。但是，重要的是所有人都可以访问我的数据库对象的同一个实例，所以如果不足以为每个模型创建一个实例。
我不太确定如何使用依赖注入实现此目的。我的第一个想法是创建一个单独的DI项目并将所有接口绑定到它们各自的实现，因此DI项目需要引用所有其他项目（模型接口和实现，数据库系统等）。然后，模型将需要访问DI项目，因为例如，他们需要从DI系统（Ninject）请求数据库系统。当然这会创建一个循环引用（将DI项目绑定到DI项目的模型和模型），所以这是不可能的。
长话短说，我需要一种编程模式，允许我将模型接口绑定到它们的实现，但这也允许模型实现从Ninject请求其他依赖项，例如。
IModel1 -> Model1
IModel2 -> Model2 (different project)
IDatabase -> Database (different project)
Model1 -> request IDatabase -> get Database instance
Model2 -> request IDatabase -> get the same Database instance
很高兴得到一些建议，目前我被困住并且没有想法;） 谢谢！
答案 0 :(得分：7)
模型需要访问DI项目，例如， 他们需要从DI系统请求数据库系统 （Ninject）
当您使用依赖注入时，模型不需要访问DI框架，因为它是注入依赖项的DI框架。模型对象不应该询问DI容器。当您的对象向容器询问依赖关系时，它不会被称为依赖注入，而是服务定位器。服务定位器is considered an anti-pattern。
我的第一个想法是创建一个单独的DI项目
当您拥有单个应用程序（即Web应用程序）时，通常要做的是在最终应用程序中完全配置DI容器，尽可能接近应用程序的入口点。这称为Composition Root。
所有模型项目都需要使用某种数据库系统，所以它们 所有人都需要访问另一个实现我所有数据库的.dll 逻辑
尝试制作POCO（普通的旧CLR对象）模型/实体对象，或者至少确保这些对象不需要引用任何其他项目，这使您的架构（和测试）更容易。
答案 1 :(得分：4)
在Register Resolve Release内使用带有Composition Root模式的Ninject。
答案 2 :(得分：1)
客户端应用程序将使用Ninject注入实际的数据库和模型实现。
因此，客户端应用程序需要引用数据库，idatabase，model和imodel项目。
idatabase和数据库项目需要引用模型项目，因为这些方法将返回模型对象或模型对象的集合。看看repository pattern。
您的模型无需参考任何项目。