我应该使用Unity(它还活着)吗？

Question

我2年前和Unity合作过,我打算再次使用它.

但是,当你谷歌搜索它时,你会进入微软网站,该网站说不再维护这些页面,而另一个重要的是在codeplex.com.

然而,在codeplex,自2010年开始以来一直没有发布,并且他们在may/6月承诺电影(我认为它们意味着2010年),但他们还没有.

所以我想知道产品是否还活着,或者MEF是新的孩子那个岩石？

ps(位offtopic)

我不知道我是否是唯一一个,但我似乎永远不会很好地了解一个代码复合项目的成熟度/状态/"它们将在明年存在"等,而且大部分时间的文档都是如此 - 所以

Answer 1

几点:

1. MEF并非旨在成为Unity的竞争产品(因此在选择IoC的主要目的时请记住这一点).微软的一名员工,格伦座,提出这这里的计算器:

   我们的目标不是将MEF作为一个通用的IoC.考虑MEF的IoC方面的最佳方式是实现细节.我们使用IoC作为模式,因为它是解决我们要解决的问题的好方法...... MEF专注于可扩展性.

2. 在P&P Unity论坛上也有一个类似的问题(从上个月开始),答案如下:

   Unity非常活跃,并且现在有一个团队正在努力(我们正在为Silverlight构建Silverlight集成包的Unity拦截支持).看看最新的下降,你会看到那里的更新.

   此外,目前有许多使用Unity的项目,包括Microsoft产品.Unity采用的脉冲非常健康 - Unity 2.0独立下载超过10万次,而EntLib下载更多.stackoverflow上Unity论坛的订阅者数量与MEF论坛相同.

3. 我强烈建议您在薄包装器后面抽象出您选择的IoC容器,以帮助您免受任何给定容器过时的风险.如果需要,它将更容易切换到不同的容器..NET中的Brownfield应用程序开发的第251页也提倡这种方法,示例代码如下(为了避免侵犯版权,我稍微改了一下):

   public class Resolve
   {
       public static T TypeOf<T>()
       {
       //…
       }
   }
   
   public class SomeClass
   {
       public void DoingSomething( )
       {
           var someDependency = Resolve.TypeOf<ISomeDependency>();
           //...
       }
   }
   

Answer 2

当涉及到微软的依赖注入产品时,MEF(Managed Extensibility Framework)和Unity目前处于竞争的角度.就截取和AOP(面向方面​​编程)而言,MEF还没有真正努力解决这个问题.

历史告诉我们,微软并没有真正管理其竞争/重叠的团队项目,结果是半实现的实施记录,往往缺乏基本功能(看看LINQ to SQL和实体框架的一个明显的例子 - 3年后,EF仍缺乏LINQ to SQL开箱即用的非常基本的功能.

我个人会选择一个更成熟,更好维护的DI框架(大多数都具有比MEF和Unity组合更多的功能).我喜欢Castle Windsor.NInject,StructureMap和其他似乎也有很好的跟踪记录.