C# 中第三方框架的包装

发布于 2024-08-14 21:27:04 字数 215 浏览 1 评论 0原文

我正在第三方框架上做一个薄包装器,我正在考虑以下选项:

  1. 完全包装框架,以便包装器的客户端不会注意到包装的框架。如果是这样,这意味着我必须从框架中包装一些类。这样包装器的客户端和被包装的框架之间就没有依赖关系。

  2. 将框架中的一些类暴露给包装器的客户端,这意味着客户端需要引用被包装的框架。

    将框架

你有什么意见?

I am doing a thin wrapper over a third-party framework, i am thinking following options:

  1. completely wrap the framework, so that the client of the wrapper will not notice the wrapped framework. if so, it means i have to wrap some classes from the framework. this way no dependency between the wrapper's client and the wrapped framework.

  2. expose some classes from the framework to the wrapper's client, it means the client is required to reference the wrapped framework.

what's your opinion?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

逆流 2024-08-21 21:27:04

我会更进一步,编写独立于框架的功能,并创建您使用的“理想”界面。

然后,在您的功能和框架之间创建一座桥梁。

如果包装器是框架的一对一翻译,则包装某人的框架不一定是巨大的胜利!您将删除二进制依赖项,但在概念上您仍然会耦合到框架,这使得在框架之外使用代码变得更加困难。

I'd go a step further, and write the functionality independent of the framework, and create "ideal" interfaces that you use.

Then, create a bridge between your functionality and the framework.

Wrapping someone's framework isn't necessarily a huge win if the wrapper is a one-to-one translation of the framework! You'll remove the binary dependency, but you'll still be conceptually coupled to the framework, making it harder to use your code outside of the framework.

魔法少女 2024-08-21 21:27:04

我想说,如果包装器的目的是使客户端应用程序独立于第三方框架,那么包装器应该包括客户端应用程序将使用的框架的所有方面。这样,第三方组件可以在不影响客户端的情况下进一步换出(假设包装器的接口设计得足够通用以“适合”另一个第三方组件)。

I'd say that if the purpose of the wrapper is to make the client application independent of the third-party framework, then the wrapper should include all the aspects of the framework that the client application will use. That way the third-party component could be swapped out further on without affecting the client (assuming the interface of the wrapper is designed to be general enough to "fit" another third-party component).

没︽人懂的悲伤 2024-08-21 21:27:04

您应该牢记框架的目的和“波动性”,但总的来说,我会选择完全包装它。这为您提供了更大的灵活性和更好的封装(例如考虑异常)

You should take the purpose and the "volatility" of the framework in mind, but in general I would opt for wrapping it completely. This gives you much more flexibility and better encapsulation (think of exceptions for example)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文