依赖注入和代码可维护性

Question

我正在开发一个(vb.net/asp.net)项目，该项目使用接口提供依赖项注入。但在我看来，代码的可维护性已经被扼杀了。当我想阅读代码时，我不能简单地跳到使用的相关类的代码。我所看到的只是接口，所以我必须在项目中搜索，以确定哪些类正在执行实现。这真的损害了我的生产力。

是的，我知道我现在可以用各种各样的替换类来实现接口。但是，例如，我知道我不会在任何时候改变我的数据源--我没有必要启用交换的能力。在我看来，所有这些依赖注入看起来都太过分了(事实上，它存在的唯一真正原因是为了支持单元测试的模拟类)。实际上，我已经读过几个地方，状态DI实际上对可维护性更好。但是，这假设您已经知道了所有内容，并且知道需要更新哪个类。找出找的地方是我要死的部分。

所以，我的问题是:是否有更好的方法来遍历代码？是否有更好的方法使代码更易于维护？我们只是做错了吗？或者这是标准的课程吗？

Answer 1

DI肯定有一些开销，特别是当您的配置与代码分离时。虽然这是正常的过程，但随着时间的推移，它确实会变得更容易处理，并且随着您对代码的更好理解。

但是，有一些工具可以帮助--看看雷夏珀或CodeRush。两者都为Visual中的代码导航体验提供了很好的改进。Resharper拥有优秀的“转到符号”或“付诸实施”方法，可以快速帮助您导航到接口的实现，无论它在哪里。

关于可维护性:一般来说，随着时间的推移，松散耦合的设计变得更加重要，因为会有变化。代码耦合得越紧密，就越难在不影响整个应用程序的情况下进行小的更改。这是取决于接口的非常重要的地方--不管您是否选择使用依赖注入。

Answer 2

可维护性是很多不同的东西。总之，它解决了您可以通过添加新特性使不断发展应用程序的程度。

是的，可能更难理解协作者是如何连接的，因此可维护性的这一方面可能会通过引入松散耦合而受到的影响。

但是，一旦您了解了代码库是如何工作的，您就应该是能够更好地添加新功能，而不需要减速。从这个意义上说，的可维护性通过松散耦合大大提高了。

不过，这不是银弹。松散耦合是可维护代码的先决条件，而不是保证。