创建使用.NET命名空间的库的最佳实践

Question

编写一个定义依赖于另一个库的接口的库是不好的做法吗？

我知道紧耦合很糟糕,但是在使用.NET类时这仍然适用吗？

例如,在.NET中,如果我有一个返回Color对象的库,它将强制在使用我的库的任何东西上依赖System.Drawing.在库中创建自己的Color-type类会更好吗？

Answer 1

我区分了易失性和稳定性依赖性.

一般来说,Color看起来像一个稳定的依赖,因为它已经在BCL中,它本质上是确定性的,不涉及任何资源密集型的进程外通信,也不依赖于其运行的特定设置 - 时间环境.

这里唯一的考虑因素是,当涉及到Color时,BCL中有不止一个这样的类,所以请确保你真的只想用你的API定位Windows Forms应用程序,因为WPF有自己的Color定义.

如果您只需要Color以某种颜色绘制UI的部分,那么内置的Color类可能很好,但是如果Color是域模型中的主要概念,并且您需要定位不同的UI(WPF, Windows Forms,Web)通过定义自己的抽象,你可能会更好.

在这种更高级的情况下,您可以随后围绕抽象创建适配器和映射器,以弥合抽象和具体Color类之间的差距.

Answer 2

如果它是一个标准的.NET库,我不会担心它.没有理由从一个类映射到另一个类...如果在下一个.NET版本中System.Color发生了变化怎么办？您还必须更改映射代码,并且可能必须相应地检测版本和映射.那是一个真正的痛苦.