依赖注入和代码可维护性
我正在开发一个（vb.net/asp.net）项目，该项目使用接口提供依赖项注入。但对我来说，感觉代码的可维护性已经被扼杀了。当我想通读代码时，我不能简单地跳转到所使用的相关类的代码。我所看到的只是接口，因此我必须搜索整个项目以找出哪些类正在执行实现。这确实损害了我的生产力。
是的，我知道我现在可以使用各种替换类来实现接口。但例如，我知道我不会很快更改我的数据源 - 我不需要启用交换数据源的功能。所有这些依赖注入对我来说似乎都太过分了（事实上，它存在的唯一真正原因是支持单元测试的模拟类）。我实际上读过一些地方，指出 DI 实际上更易于维护。但这假设您已经知道所有内容在哪里并且知道需要更新哪个类。找出该往哪里看才是让我苦恼的部分。
所以，我的问题是：有没有更好的方法来遍历代码？有没有更好的方法让代码更易于维护？我们只是做错了吗？或者这是课程的标准吗？
I am working on a (vb.net/asp.net) project that is using interfaces to provide dependency injection. But to me, it feels like the maintainability of the code has been killed. When I want to read through the code, I can't simply jump to the code of a related class that is used. All I see are the interfaces, and so I have to hunt through the project to figure out what classes are doing the implementation. This really hurts my productivity.
Yes, I know I now can implement the interfaces with a wide variety of replacement classes. But for example, I know I'm not changing my data source any time soon--there is no need for me to enable the ability to swap that out. All of this dependency injection seems like overkill to me (in fact, the only real reason it is there is to support mock classes for unit testing). I've actually read several places that state DI is actually better for maintainability. But that assumes you already know where everything is and you know which class you need to update. Finding out where to look is the part that is killing me.
So, my question is: Is there a better way to traverse through the code? Is there a better way to make the code more maintainable? Are we just doing it wrong? Or is this par for the course?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
DI 肯定会产生一些开销，尤其是当您的配置与代码分离时。虽然这对于课程来说是正常的，但随着时间的推移，并且当您对代码有了更好的理解时，它确实会变得更容易处理。
但是，有一些工具可以提供帮助 - 查看 Resharper 或CodeRush。两者都对 Visual Studio 中的代码导航体验提供了出色的改进。 Resharper 具有出色的“转到符号” 或 "转到实现" 方法可快速帮助您导航到界面的实现（无论其位于何处）是。
关于可维护性：一般来说，随着时间的推移，松散耦合的设计变得更加重要，因为将会发生变化。代码耦合得越紧密，就越难在不影响整个应用程序的情况下进行小的更改。这就是依赖接口非常重要的地方——无论您是否选择使用依赖注入。
There is definitely some overhead to DI, especially when your configuration is separated from your code. While this is par for the course, it does get easier to deal with over time, and as you get a better understanding of the code.
However, there is tooling that can help - Have a look at Resharper or CodeRush. Both offer excellent improvements to the code navigation experience in Visual Studio. Resharper has excellent "Go To Symbol" or "Go To Implementation" methods that quickly help you navigate to the implementation of your interface, wherever it may be.
To the point about maintainability: In general, a loosely coupled design becomes more important as time passes, because there will be change. The more tightly coupled your code is, the harder it is to make small changes without affecting the overall application. This is where depending on interfaces is very very important -- whether or not you choose to use Dependency Injection.
可维护性有很多不同的含义。总体而言，它解决了您可以通过添加新功能来不断发展应用程序的程度。
是的，理解协作者如何连接可能会变得更加困难，因此通过引入松散耦合，可维护性可能会受到影响。
但是，一旦您了解了代码库的工作原理，您应该能够更好在不减慢速度的情况下添加新功能。从这个意义上说，松散耦合可维护性大大提高。
但这不是灵丹妙药。松耦合是可维护代码的先决条件，而不是保证。
Maintainability is many different things. Overall, it addresses the degree to which you can keep evolving an application by adding new features.
Yes, it may become more difficult to understand how collaborators are connected, so that aspect of maintainability may suffer by introducing loose coupling.
However, once you've figured out how the code base works, you should be better able to add new features without slowing down. In that sense, maintainability is much improved by loose coupling.
It's not a silver bullet, though. Loose coupling is a prerequisite for maintainable code, not a guarantee.