2010-07-20 42 views
3

我可以限制来自特定名称空间的类引用另一个特定名称空间中的类吗?这两个名称空间都存在于同一个.NET程序集中。我可以强制C#中名称空间之间的依赖关系吗?

例子:

namespace LegacyCode 
{ 
    class LegacyClass { ... } 
} 

namespace NewCode 
{ 
    class NewClass {...} 
} 

我不想从“NewCode”类能够引用类的“遗留代码”。

选项:

  1. 有不同的组件(使部署困难,构建需要更长的时间)
  2. 使用像NDetect工具(费钱!)

没有人有任何其他的想法?

回答

10

考虑与Obsolete attribute标记的类。这会导致任何本身未标记为“Obsolete”的代码在编译期间生成警告。

启用“将警告视为错误”的项目文件的“构建”选项卡上的设置,以使此警告与错误失败编译代替。

编辑:

同意,独立的组件是为了便于淡出这个代码一个很好的策略。这不会阻止人们提及它。过时的属性表明这个代码已经过时了。

编辑#2:

感谢Dan Tao您指出过时属性的overloaded constructor。这意味着您可以强制使用某件事物是否应视为错误,而不必将警告视为错误。还有一个有用的选项可以指定一条消息来指导用户解决方法。此消息在编译期间显示在错误/警告中。

+1

其中一个'ObsoleteAttribute'类的重载[构造函数](http://msdn.microsoft.com/zh-cn/library/961hff5d.aspx)需要一个'bool'参数来指定对标记类的引用是否应该导致编译错误。 – 2010-07-20 15:25:02

+0

谢谢丹 - 我以前从未注意到! – MPritchard 2010-07-20 15:29:41

7

记录设计,与人交谈,审查代码。不要试图把技术扔在人们的问题上。 (审查部分可以成为像NDetect工具更有效,虽然)。

如果你真的需要设计变更的隔离,去单独的组件:这是预期的设计机制。但要确保你有一个合理的版本控制方案,无论是接口还是实现。

+0

原则上我认为你是对的 - 那是我们目前的解决方案(沟通规则)。 但实际上这并没有奏效。一位经验丰富的开发人员检查了一个打破依赖性的新课程 - 审查人员也错过了这个课程。这就是为什么我想要更严格的控制方式。 – GarethOwen 2010-07-20 13:15:53

+2

好听!我认为你必须硬着头皮接受费用,或者以单独的程序集管理的形式,或者依赖执行工具。我不知道有任何NDepend的自由替代品(当然不包括它的功能集)。但是,依赖打破会花费你的钱,特别是如果维护几年 - 前期投资,以避免后来的技术债务听起来更可取。 – 2010-07-20 13:27:56

3

我认为单独的程序集是唯一可行的解​​决方案。

3

MS使用System.ObsoleteAttribute属性来标记过时的/传统的代码。该属性提供了一个创建编译器错误的ctor。虽然,如果没有太多遗留类,我会使用它。

+0

我不知道Obsolete属性 - 听起来不错。但不幸的是,我们确实有很多遗留类:( – GarethOwen 2010-07-20 13:17:14

+2

相信我 - 花费一个下午复制和粘贴[Obsolete]是值得的。如果您的代码在文件夹中正确布局,那么所有过时的代码都在同一个文件夹中,尝试在Visual Studio中使用正则表达式来查找和替换我认为您希望将其应用于类,枚举和结构 – MPritchard 2010-07-20 13:21:39

+0

老板不太满意将90%的代码库标记为Obsolete – GarethOwen 2010-07-20 13:30:18

1

正如其他人所说,使用过时的属性(即使你有将其重命名)。

但更进一步。删除任何不再使用的传统方法。这会阻止某人稍后使用它。由于过时的属性会随着时间的推移而下降,因此您应该开始查看编译器警告。

您甚至可以每天进行一小时的测试,以尽可能多地消除编译器警告......也许您在下班后为每日赢家购买啤酒(或软饮料......)。

+1

我们将其作为构建统计添加到我们的TeamCity构建中。看到一个缓慢趋势为0的图有一些好处 – MPritchard 2010-07-20 15:29:20

相关问题