但是,胖客户端应用程序的情况有所不同.我必须创建自己的对象,或者我必须恢复到服务定位器样式方法,我要求内核(可能通过某个接口,允许可测试性)给我一个完整的依赖项对象.
但是,我已经看到Service Locator被描述为反模式的几个地方.
所以我的问题是 – 如果我想在我的胖客户端应用程序中受益于Ninject,是否有更好/更正确的方法来获得所有这些？
>可测试性
>适当的DI / IoC
>可能的耦合量最小
请注意,我不只是在这里讨论MVVM并将视图模型放入视图中.这特别是需要从内核提供存储库类型对象,然后从该存储库中获取的实体注入了功能(当然数据来自数据库,但它们也需要一些对象作为参数,具体取决于状态世界,Ninject知道如何提供).我可以以某种方式做到这一点,而不会将存储库和实体都作为不可测试的混乱吗？
如果有什么不清楚,请告诉我.谢谢！
编辑7月14日
我确信提供的两个答案可能是正确的.然而,我身体的每一根纤维都在对抗这种变化;其中一些可能是由于缺乏知识造成的,但也有一个具体原因导致我无法看到这种做事方式的优雅;
我没有在原始问题中解释得这么好,但问题是我正在编写一个库,将被几个(首先是4-5,可能更晚)的WPF客户端应用程序使用.这些应用程序都在相同的域模型等上运行,因此将它们保存在一个库中是保持DRY的唯一方法.但是,该系统的客户也有可能编写自己的客户端 – 我希望他们有一个简单,干净的库来与之交谈.我不想强迫他们在他们的作文根中使用DI(在他的书中使用像Mark Seeman这样的术语) – 因为与他们相比,只需要新建一个MyCrazySystemAdapter()并使用它就可以使事情复杂化.
现在,MyCrazySystemAdapter(因为我知道人们会在这里不同意我选择的名称)需要由子组件组成,并使用DI组合在一起. MyCrazySystemAdapter本身不需要注入.它是客户端与系统通信所需的唯一接口.所以一个客户应该得到其中的一个,DI就像幕后的魔法一样,而对象是由许多不同的对象使用最佳实践和原则组成的.
我确实意识到这将是一种有争议的想要做事的方式.但是,我也知道将成为此API客户的人员.如果他们发现他们需要学习并连接DI系统,并在他们的应用程序入口点(Composition Root)中提前创建他们的整个对象结构,而不是新建一个对象,他们会给我中指和直接搞乱数据库并以你难以想象的方式搞砸了.
TL; DR：为客户端提供结构合理的API太麻烦了.我的API需要提供一个单独的对象 – 使用DI和适当的实践在幕后构建 – 他们可以使用.现实世界有时胜过为了坚持模式和实践而向后建造一切的愿望.
基本上,您应该在app.xaml中构建完整的应用程序.如果稍后需要创建某些部分,因为您还不知道在启动时创建它们的所有内容,则将工厂注入接口(请参阅下文)或Func(请参阅Does Ninject support Func (auto generated factory)?)到需要创建此实例的类中.两者都将在下一个Ninject版本中得到本地支持.
例如
public interface IFooFactory { IFoo CreateFoo(); }
public class FooFactory : IFooFactory
{
private IKernel kernel;
FooFactory(IKernel kernel)
{
this.kernel = kernel;
}
public IFoo CreateFoo()
{
this.kernel.Get<IFoo>();
}
}
请注意,工厂实现在逻辑上属于容器配置,而不属于业务类的实现.