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

Question

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

我知道紧密耦合是不好的，但是在使用.NET类时，这仍然适用吗？

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

Answer 1

我区分易变和稳定依赖项 。

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

这里唯一要考虑的是，涉及Color时，BCL中有多个这样的类，因此请确保您确实要使用API​​定位Windows Forms应用程序，因为WPF有其自己的Color定义。

如果您只需要Color即可将用户界面的某些部分绘制成某种颜色，则内置的Color类可能很好，但是如果Color是您的域模型中的主要概念，则您需要定位不同的UI（WPF， Windows Forms，Web），最好定义自己的抽象。

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

Answer 2

如果它是一个标准的.NET库，我就不用担心。 没有理由将一个类映射到另一个类...如果System.Color在下一个.NET版本中发生了更改，该怎么办？ 您也必须更改映射代码，并且可能必须检测版本并进行相应的映射。 那真是痛苦。

Answer 3

在所有库中，我返回仅依赖库中对象的对象。

我会问自己为什么要编写一个依赖于另一个非隐式命名空间的库。 它似乎与整个“封装”概念背道而驰。

因此，仅凭我自己的OOP推理和知识，我会说您在返回自己的非依赖对象的正确轨道上。

Answer 4

你提出了一个很好的问题。 答案是：这取决于。 如果标准库始终可用，那就很好了； 核心库始终引用不同的.DLL。

对于第三方库，您会遇到问题。 如果有其他事情可以满足您的需要，那么自己动手滚动并不是一个好主意，但是您却依赖于另一个库，这对用户来说是一个后勤问题。

这里没有正确的答案，您只需要选择最适合您的项目的方法即可。 尝试使耦合尽可能地分离，是的，但是有时您只是抱紧拥抱并完成工作。

Answer 5

这取决于您对课程的使用情况。

如果您需要从Color类的实例中获取系统Color类的实例（例如，如果绘制到Windows窗体），则最好使用System类-这样可以省去在两种类型之间进行转换，并为您提供了可以免费使用Color类的所有“功能”（例如，内置的“红色”，“黑色”，“绿色”等常量）的优点。

如果在另一方面，你只是用任意的RGB值的工作（也许是科学计算）， 绝不需要转换为System.Color的实例，那么它可能是有意义的创建自己的类。

很有可能您最好使用System.Color类-是的，封装是个好主意，但是不以节省大量时间为代价！

Answer 6

您不必担心在.NET核心库中使用任何东西。 没有它，编写DLL不会走得太远。 唯一可能需要注意的地方是System.Web命名空间，因为我相信.NET 4具有客户端配置文件安装程序，这基本上意味着，如果您使用此安装程序，它将仅安装预期在客户端上使用的内容。 我个人认为这对Microsoft而言不是一个好主意，因为它只会增加不必要的复杂性，从而节省少量的下载时间。