看看Microsoft的Managed Extensibility Framework(MEF)和各种IoC容器(例如Unity),我没有看到何时使用一种类型的解决方案而不是另一种.更具体地说,似乎MEF处理大多数IoC类型模式,并且像Unity那样的IoC容器不是必需的.
理想情况下,我希望看到一个很好的用例,其中将使用IoC容器代替MEF或者除了MEF之外.
Unity依赖注入容器似乎是一个众所周知的问题,其中SynchronizedLifetimeManager经常会导致Monitor.Exit方法抛出SynchronizationLockException,然后捕获并忽略它.这对我来说是一个问题,因为我喜欢使用Visual Studio进行调试以打破任何抛出的异常,所以每次我的应用程序启动时,我都会无缘无故地多次打破这个异常.
如何防止抛出此异常？
无论在Web上的其他地方提到此问题,建议通常都涉及更改调试器设置以忽略它.这类似于去看医生并且说:"医生,医生,当我举起它时,我的手臂疼,"被告知,"好吧,停止提高它." 我正在寻找一种解决方案,可以阻止异常被抛出.
SetValue方法中发生异常,因为它假设首先调用GetValue,并调用Monitor.Enter.但是,LifetimeStrategy和UnityDefaultBehaviorExtension类都会定期调用SetValue而不调用GetValue.
我宁愿不必更改源代码并维护我自己的Unity版本,所以我希望有一个解决方案,我可以在容器中添加一些扩展,策略或策略的组合,以确保,如果生命周期管理器是一个SynchronizedLifetimeManager,GetValue始终先调用.
现在有很多依赖 注入框架可供选择.由于您使用的库,您以前经常被迫使用给定的依赖注入框架.但是,Common Service Locator库使库代码独立于注入框架.
学习所有这些所需的时间足以决定使用哪个是不合理的.我不相信我们已经达到了可以讨论最佳依赖注入框架的阶段.那么我应该问什么问题关于项目和我自己来帮助决定在特定情况下使用的最佳依赖注入框架？
了解为什么选择当前使用的依赖注入框架以及您是否仍然对此选择感到满意也很有用.
在比较依赖注入框架的样式时,是否还有一个有用的词汇表？
服务定位器库是否在现实生活中工作,或者您是否被迫在同一项目中使用许多不同的依赖注入框架？
使用每个依赖注入框架对代码进行折射是多么容易,例如ReSharper等工具是否适用于给定的框架？
我正在使用Unity IoC容器.这真的不是我做出的决定,它只是与Prism一起来的,我只是坚持下去.我从未使用任何其他IoC框架,我必须承认我对Unity非常满意.然而,满意度可能来自无知,因为我不知道其他框架提供了什么.
我一直听说我不应该使用Unity IoC容器.人们说,"使用Castle,nInject或StructureMap",但我仍然没有听到任何具体的论据或例子,为什么我应该使用不同的框架.那么,为什么我不应该使用Unity？或许我应该？
目前有很多针对.NET的DI/IoC框架(http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersIOC.aspx).我觉得很难选择.因此,我想衡量一下公众意见,看看哪个框架最受欢迎 - 所以请在这里发布您最喜欢的框架并让人们投票......
我正在寻找有关如何为ASP.NET MVC应用程序选择IoC容器的一些指导.
(例如)StructureMap,Ninject,Castle Windsor,Unity,autofac和其他人之间有什么区别？任何人都可以提供一些提示或链接到可能有助于选择一个库的资源吗？
更新:有一个问题(Enterprise Library Unity vs其他IoC容器),它讨论了IoC容器初始化的差异.
但是功能上是否有任何差异,这会使一些IoC容器成为ASP.NET MVC应用程序的更好选择？
我想知道asp.net mvc有什么好的简单IoC框架？有很好的文档,很容易起床和去.
谢谢
我们有一个MVC3应用程序,我们创建了许多小动作和视图来处理将数据放在我们需要的任何地方.例如,如果它是一个博客,我们想要显示评论,我们有一个评论操作和视图,我们可以将它放在我们想要的任何地方,用户个人资料视图和博客文章视图等.
由于我们在应用程序中拥有的所有其他小视图,所导致的问题是每个小视图或操作需要每次页面加载多次调用同一服务.因此,在包含这些小视图的非常大的页面上,我们可能有80多个sql调用,其中40%是重复的,然后页面变慢.当前的解决方案是缓存一些数据,并在ViewBag中传递一些数据,如果我们可以这样,如果你想要用户的配置文件,你检查它的缓存或ViewBag是否没有要求它.
对于一个设计模式来说,这真的很脏,并且viewbag方法看起来很糟糕,因为它必须从顶部向下传递.我们已经在HttpCurrent.Items中添加了一些数据,以便根据请求(而不是缓存,因为数据可以更改),但是必须有一些干净的解决方案,感觉不对,也是干净的？
编辑
我被要求更具体,虽然这是一个内部业务应用程序,但我无法泄露大部分具体细节.
所以把它变成软件类比.让我们将它与facebook进行比较.想象一下,这个MVC应用程序对每个facebook帖子都有一个动作,然后在该动作下它对于like按钮和注释数量有另一个动作,然后是向用户显示最高评论的另一个动作.我们的应用程序设计方式我们会在每个操作中获取当前用户配置文件(因此在上述情况下最少为4次),然后子操作将获得父墙贴文以验证您是否有权查看它.现在你可以考虑缓存每个安全检查,墙贴等的调用,但我觉得缓存是针对应用程序生命周期中需要的东西,而不仅仅是在这里和那里的小块来纠正你的错误应用程序是架构的.