相关疑难解决方法(0)

使用Enterprise Library Unity与其他IoC容器(Windsor,Spring.Net,Autofac ..)的优缺点是什么？

我刚开始学习DI(我正在研究WPF/Silverlight,但我有计划转向ASP.NET).在我从互联网上阅读了一些DI文章之后,有两个我感兴趣的框架,MEF和Unity.我想知道它们之间的真实世界有什么不同,哪一个是好的.

我想要创建的是一个Silverlight应用程序,其中包含一些选项卡/模块,这些选项卡/模块都将是单独的DLL.

我看到PRISM有Shell/Module概念,似乎是针对UI做的,我找到了一个很好的演示(展示了如何搜索digg/twitter).

但听起来MEF将包含在VS2010中,所以我想选择这个选项.

谁能以某种方式清楚地解释这些差异？(我不是高级程序员)

在这里和这里找到了几个好的(相关的)问题,但都差不多有一年了.

我想知道在棱镜发展的当前背景下什么是更好或者至少是每种情况更好的情况.

在工作中,我们经常使用Unity.它的功能非常棒,但您使用的越多,配置文件越多,运行时问题就越多,您为每个测试项目重新创建统一配置的次数就越多.

因此,我们最终与具有翻过几个项目被复制,当谈到时间部署,你最终不得不追查你忘记添加到引用的DLL一个巨大的统一配置部分,但你只发现这些在运行时.不好玩.

我猜测有人遇到过这个问题而且有一个解决方案.理想情况下,我想弄清楚如何以一种使用约定优于配置的方式配置Unity,并减少运行时问题(即,庞大的配置文件).有人知道用最小配置实现Unity的好方法吗？

编辑:有一件事:我必须坚持只使用Unity.无法真正切换到Ninject等

MEF 不是 IoC 容器.但它似乎几乎是一个IoC容器.似乎我可以很容易地使MEF表现得像IoC容器(见下面的例子),并且没有太多的缺失使MEF成为一个完整的IoC容器.

MEF中缺少哪些实际功能,StrucureMap,Unity等必须达到标准？

你认为,这个特殊的要求有意义吗？

using System;  
using System.Collections.Generic;  
using System.ComponentModel.Composition;  
using System.ComponentModel.Composition.Hosting;  
using System.ComponentModel.Composition.Primitives;  
using System.Linq;  
...
private CompositionContainer container;
public void Configure()  
{  
    container = CompositionHost.Initialize(  
        new AggregateCatalog(
            AssemblySource.Instance.Select(
              x => new AssemblyCatalog(x)).OfType<ComposablePartCatalog>()));       
        var batch = new CompositionBatch();        
        batch.AddExportedValue<IWindowManager>(new WindowManager());  
        batch.AddExportedValue<IEventAggregator>(new EventAggregator());  
        batch.AddExportedValue(container);        
        container.Compose(batch);  
 }  

在哪种情况下我们应该使用什么？在什么情况下我们会选择一起使用？