Unity自动装配:使用或不使用？

Question

Unity自动装配:使用或不使用？

lor*_*ini 5 c# unit-testing unity-container autowired

似乎与新的统一版本已添加支持自动装配.

你们当中有多少人熟悉它并强烈建议我使用或不使用它？在我看来,使用它限制了我对DI的控制,特别是对于单元测试的方面,我认为错了吗？

Answer 1

Mar*_*ann 20

我假设这个问题是关于自动注册的,因为Unity已经有多年的自动连接.

自从几年前我写了" 何时使用DI容器"这篇文章以来,我对DI容器的态度只会略显激进.在那篇文章中,我描述了使用DI容器的好处和权衡,而不是穷人的DI(手动编写代码).

我的偏好顺序现在是:

手动编写组合根(穷人的DI)的代码.这可能看起来很麻烦,但为您提供了最好的反馈,并且比使用DI容器更容易理解.
使用自动注册(AKA约定优于配置).虽然您丢失了编译时反馈,但该机制实际上可能会使您的代码更加一致,因为只要遵循惯例,事情就会"正常工作".但是,这要求团队对所选DI容器的自动注册API感到满意,根据我的经验,这可能不是这种情况.
如果你有一个非常令人信服的理由,那么只能使用显式注册(并且不:不完全理解DI不是一个好理由).这些天,我几乎从不这样做,所以我很难想出一些好的案例,但高级终身管理可能是一个动机.

自从我上次在任何生产代码中使用DI容器以来已有1年半的时间了.

总之,并努力回答有关Unity的具体问题:

认真考虑根本不使用Unity(或任何其他DI容器).
如果必须使用Unity,请使用自动注册功能.否则,你可能会遇到更多麻烦而不是从中受益.

警告:根据我对DI和各种DI容器(包括显式注册和自动注册)的经验,我将此作为一般回复.虽然我对Unity的早期版本有一些了解,但我对Unity新版本的自动注册功能一无所知.

因此,更容易处理像"var service = new Service(new Repository(new DbContext(new DbConnection)))"这样的东西,而不是团队(显然是小辈)学习和理解一个简单的概念？那么去耦,测试呢？手动完成DI只是等待发生的艰苦工作. (3认同)
@MikeSW是的,处理那种代码要容易得多,但它并不是*无处不在*,它只存在于[Composition Root]中(http://blog.ploeh.dk/2011/07/28/CompositionRoot),因此应用程序的其余部分(99%)与往常一样松散耦合和可测试 - 您不需要DI容器; [相反](http://stackoverflow.com/a/1465896/126014),我应该说......而且,再说一次,根据我自己的经验,不仅是那些害怕DI Container'魔术'的少年. (3认同)
我没有看到_ NOT_使用DI容器的原因是非常重要的.设置一分钟和几分钟来注册一些约定需要1分钟.最多5分钟,现在你只添加新类型,他们神奇地工作. (2认同)
@MikeSW根据我的经验,团队中有一个人了解"神奇"的运作方式(曾经是我).其他人都害怕它,它造成了一个团队瓶颈,这可能是不可取的.从技术上讲,自动注册可能没问题,但是当你考虑团队动态时,情况会发生变化.另外,根据我的经验,从编译时反馈到运行时反馈的交易通常不能保证稍微容易一点的构图. (2认同)
那些代码样本只让我确信DI Container真的是最简单的出路.它可能只是我,但我发现理解和更改代码比容器类型注册更难. (2认同)
@MikeSW我明白为什么你更喜欢约会而不是那样的东西.我唯一可以说的是,*根据我的经验*,这不是大多数团队成员想要的...... (2认同)

归档时间：	11 年，6 月前
查看次数：	2982 次
最近记录：	11 年，6 月前