8

我正在开发一个(vb.net/asp.net)项目,该项目使用接口提供依赖注入。但对我来说,感觉就像代码的可维护性已经被扼杀了。当我想通读代码时,我不能简单地跳转到使用的相关类的代码。我看到的只是接口,所以我必须通过项目来找出哪些类正在执行实现。这真的伤害了我的工作效率。

是的,我知道我现在可以使用各种替换类来实现接口。但是,例如,我知道我不会很快更改我的数据源——我不需要启用将其换出的能力。所有这些依赖注入对我来说似乎都是多余的(事实上,它存在的唯一真正原因是支持用于单元测试的模拟类)。我实际上已经阅读了几个地方,状态 DI 实际上更利于可维护性。但这假设您已经知道所有内容在哪里,并且您知道需要更新哪个类。找出在哪里看是杀死我的部分。

所以,我的问题是:有没有更好的方法来遍历代码?有没有更好的方法让代码更易于维护?我们只是做错了吗?或者这是课程的标准杆?

4

2 回答 2

5

DI 肯定有一些开销,尤其是当您的配置与代码分离时。虽然这课程的标准,但随着时间的推移,它确实会变得更容易处理,并且随着您对代码的更好理解。

但是,有一些工具可以提供帮助——看看ResharperCodeRush。两者都为 Visual Studio 中的代码导航体验提供了出色的改进。Resharper 具有出色的“转到符号”“转到实现”方法,可以快速帮助您导航到接口的实现,无论它在哪里。

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

于 2010-10-30T05:46:38.183 回答
4

可维护性是许多不同的东西。总体而言,它解决了您可以通过添加新功能来不断发展应用程序的程度。

是的,理解协作者是如何连接的可能会变得更加困难,因此可维护性方面可能会因引入松散耦合而受到影响。

但是,一旦您弄清楚了代码库的工作原理,您应该能够更好地添加新功能而不会放慢速度。从这个意义上说,松散耦合大大提高了可维护性。

不过,这不是灵丹妙药。松耦合是可维护代码的先决条件,而不是保证。

于 2010-11-01T09:23:38.387 回答