创建使用 .NET 命名空间的库的最佳实践
编写一个定义依赖于另一个库的接口的库是一种不好的做法吗？
我知道紧密耦合不好，但是在使用 .NET 类时这仍然适用吗？
例如，在 .NET 中，如果我有一个返回 Color 对象的库，它将强制使用我的库的任何内容都依赖于 System.Drawing。在我的库中创建自己的颜色类型类会更好吗？
Is it bad practice to write a library that defines an interface dependent on another library?
I know tight coupling is bad, but does this still apply when using .NET classes?
For example, in .NET, if I have a library that returns a Color object, it would force a dependancy on System.Drawing on anything that uses my library. Would I be better off creating my own Color-type class inside my library?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我区分易失性和稳定的依赖关系。
一般来说，Color 看起来像一个稳定的依赖项，因为它已经在 BCL 中，它本质上是确定性的，不涉及任何资源密集型的进程外通信，而且它也不依赖于其运行的特定设置。时间环境。
这里唯一需要考虑的是，当谈到颜色时，BCL 中有多个这样的类，因此请确保您的 API 确实只针对 Windows 窗体应用程序，因为 WPF 有自己的颜色定义。
如果您只需要 Color 以某种颜色绘制 UI 的各个部分，那么内置 Color 类可能就可以了，但是如果 Color 是域模型中的主要概念，并且您需要针对不同的 UI（WPF、 Windows 窗体、Web）通过定义自己的抽象可能会更好。
在这种更高级的情况下，您可以随后围绕抽象创建适配器和映射器，以弥合抽象和具体 Color 类之间的差距。
I distinguish between Volatile and Stable Dependencies.
In general, Color looks like a Stable Dependency because it's already in the BCL, it's deterministic in nature and doesn't involve any resource-intensive out-of process communication, and neither does it rely on a particular set-up of its run-time environment.
The only consideration here is that when it comes to Color, there are more than one such class in the BCL, so make sure that you really mean to target only Windows Forms applications with your API, because WPF has its own definition of Color.
If you just need the Color to paint parts of the UI in a certain color, then the built-in Color class is probably fine, but if Color is a main concept in your Domain Model, and you need to target different UIs (WPF, Windows Forms, Web) you would probably be better of by defining your own abstraction.
In such a more advanced case, you could subsequently create Adapters and Mappers around your abstraction to bridge the gap between the abstraction and the concrete Color classes.
如果它是标准的 .NET 库，我就不会担心。没有理由从一个类映射到另一个类...如果 System.Color 在下一个 .NET 版本中发生更改怎么办？您还必须更改映射代码，并且可能必须检测版本并相应地进行映射。那真是痛苦。
If it's a standard .NET library, I wouldn't worry about it. No reason to map from one class to another ... what if System.Color changed in the next .NET release? You'd have to change your mapping code too, and possibly have to detect the version and map accordingly. That's a real pain.
对于我的所有库，我返回仅依赖于库中的内容的对象。
我会问自己为什么要编写一个依赖于另一个非隐式命名空间的库。这似乎违背了整个“封装”的概念。
因此，根据我自己的推理和 OOP 知识，我想说您在返回自己的非依赖对象方面走在正确的道路上。
With all of my libraries, I return objects that depend only on things in the library.
I would ask myself why I was writing a library that would depend upon another namespace that was not implicit. It seems to go against the whole "Encapsulation" concept.
So just by going off of my own reasoning and knowledge of OOP, I would say you are on the right track with returning your own non-dependent object.
你提出了一个很好的问题。答案是：视情况而定。如果标准库始终可用，那就没问题；核心库始终引用不同的.DLL。
对于第三方库，您会遇到问题。如果其他库可以满足您的需求，那么自行推出并不总是一个好主意，但是您会依赖另一个库，这对用户来说是一个后勤问题。
这里没有正确的答案，您只需选择对您的项目最有意义的答案即可。是的，尝试尽可能地脱钩，但有时你只需要拥抱并完成工作。
You pose an excellent question. The answer is: it depends. In the case of standard libraries that will always be available, then it's fine; the core library references different .DLLs all the time.
In the case of a third party library you run into issues. It's not always a good idea to roll your own if something else does what you want, but then you have a dependency on another library, which is a logistical problem for users.
There's no right answer here, you just have to go with what makes the most sense for your project. Try to decouple as much as possible, yes, but sometimes you just gotta cuddle up and get the job done.
这取决于您对该类的使用。
如果您需要从 Color 类的实例获取系统 Color 类的实例（例如，如果您绘制到 Windows 窗体），那么最好使用 System 类 - 它可以节省您的精力在两种类型之间进行转换，并为您提供能够免费使用 Color 类的所有“功能”的优势（例如“红色”、“黑色”、“绿色”等的内置常量...
如果打开 您只需使用任意 RGB 值（可能用于科学计算）并且永远不需要转换为 System.Color 的实例，那么创建自己的类可能是有意义的。
另一方面， 可能您最好使用 System.Color 类 - 是的，封装和所有这些都是一个好主意，但不会以节省您大量时间为代价！
It depends on your usage of the class.
If you ever need to obtain an instance of the system Color class from an instance of your Color class (for example if you draw to a windows form) then it would be better to use the System class - it saves you the effort of having to convert between the two types and gives you the advantage of being able to use all the "Features" of the Color class for free (such as built in constants for "Red", "Black", "Green" etc...
If on the other hand you are simply working with arbitrary RGB values (perhaps for scientific calculations) and never need to convert to an instance of System.Color, then it might make sense to create your own class.
In all likelihood you are better off using the System.Color class - yes encapsulation and all that is a good idea, however not at the expense of saving you massive amounts of time!
您不必担心使用 .NET 核心库中的任何内容。如果没有它，你就无法在编写 DLL 方面取得很大进展。唯一需要小心的地方是 System.Web 命名空间，因为我相信 .NET 4 有一个客户端配置文件安装程序，这基本上意味着如果您使用此安装程序，它只会安装预期在客户端上使用的内容。我个人认为这对微软来说是一个坏主意，因为它只是为了节省少量的下载时间而增加了不必要的复杂性。
You shouldn't worry about using anything in the .NET core library. You wouldn't get very far in writing a DLL without it. The only place possibly to be careful around it is the System.Web namespace as I believe .NET 4 has a client profile installer which basically means if you use this installer it will only install things expected to be used on a client. I personally think it is a bad idea on Microsoft's Part as it just adds un-necessary complication for saving a small amount of download time.