为什么不鼓励伞架？ [英] Why are umbrella frameworks discouraged?

问题描述

我想分发框架A.框架A取决于框架B.我想让我的框架的用户只需要包括框架A，但仍然可以编程访问框架B.

I want to distribute Framework A. Framework A depends on Framework B. I want a user of my framework to only need to include Framework A, but still have programmatic access to Framework B.

Apple一直使用Umbrella Frameworks的概念，但在文档中有这个主题：

Apple does this all the time using the concept of "Umbrella Frameworks", but there is this topic in the docs:

不创建伞框架

虽然可以使用Xcode创建伞框架，但执行
大多数开发者和不推荐。 Apple
使用伞框架来掩盖操作系统中
库之间的一些相互依赖性。在几乎所有情况下，你应该是
能够包括你的代码在一个单一的，标准框架包。
或者，如果你的代码是足够模块化的，你可以创建
多个框架，但在这种情况下，
模块之间的依赖关系将是最小的或不存在，不应该保证
为他们创造一个伞。

While it is possible to create umbrella frameworks using Xcode, doing so is unnecessary for most developers and is not recommended. Apple uses umbrella frameworks to mask some of the interdependencies between libraries in the operating system. In nearly all cases, you should be able to include your code in a single, standard framework bundle. Alternatively, if your code was sufficiently modular, you could create multiple frameworks, but in that case, the dependencies between modules would be minimal or nonexistent and should not warrant the creation of an umbrella for them.

为什么这种方法不鼓励？什么使它成为苹果的相互依赖框架问题的好解决方案，但不是我的？

Why is this approach discouraged? What makes it a good solution for Apple's problem of interdependent frameworks but not for mine?

推荐答案

是所有相关框架的唯一分销商，您将把所有框架一起封装为单个版本化包，这些包将一起升级。如果这是你的情况，那很好，但这是一个非常不寻常的情况。在可可开发世界中，除了苹果之外，任何人都非常不寻常。

Umbrella frameworks only make sense if you are the only distributor of all the involved frameworks, and you will be packaging all the frameworks together as a single versioned package which will be upgraded together. If that is your situation, then that's fine, but this is a very unusual situation. In the Cocoa development world, it is exceedingly unusual for anyone but Apple to be in this situation.

首先，伞框架只有在你是唯一的分配器的给定框架。例如，假设您想要将libcurl作为伞架的一部分。现在一些其他打包程序也想包括libcurl作为他的伞框架的一部分。现在我们有一个链接时间冲突，可能导致链接错误或更糟糕，未定义的运行时行为。我已经追逐了这些。他们非常不愉快。避免这种情况的唯一方法是每个框架/库只有一个版本。伞框架鼓励相反的。

To the first point, umbrella frameworks only make sense if you are the only distributor of the given frameworks. For example, say that you wanted to include libcurl as part of your umbrella framework. Now some other packager also wants to include libcurl as part of his umbrella framework. Now we have a link-time collision that can lead to either link errors or worse, undefined runtime behavior. I've chased these down myself. They're extremely unpleasant. The only way to avoid this is for there to be only a single version of each framework/library. Umbrella frameworks encourage the opposite.

即使你只是把你自己的代码分解成子片段，这意味着其他供应商可能在你自己的伞架框架中使用你的子框架，导致回到同样的问题。记住，如果你说你是第三方使用伞框架，那么对其他供应商也是可以的。

Even if you are just breaking up your own code into subpieces, this means that other vendors might use your sub-frameworks in their own umbrella frameworks, leading back to the same problem. Remember, if you say it's ok for you as a third party to use umbrella frameworks, then it's ok for other vendors too.

第二点，感觉如果你控制所有子框架的版本控制。尝试修补一个相互依赖的框架集几乎总是在我的经验是一个灾难。

To the second point, umbrella frameworks only make sense if you control the versioning of all the sub-frameworks. Trying to patch one piece of an inter-dependent set of frameworks is almost always a disaster in my experience.

操作系统供应商有一个不寻常的情况，由于大小和无处不在的系统。在一个尺度上有意义的东西在另一个尺度上往往没有意义。 NSResponder是完全正确的。当您提供一个完整的，多千个包环境，作为为该平台编写的每个程序的基础时，权衡是不同的。但是，即使苹果只有一小部分大型伞架，他们总是围绕图书馆，他们提供和控制的版本的包装。这主要是为了简化开发人员的工作，否则开发人员必须追逐几十个库和框架来编译。没有第三方有这种情况，所以很少有第三方需要这个解决方案。要求客户链接两个库是完全不同的，然后要求他们链接20.如果你提供20个框架，所有的协作和控制，那么也许你应该使用一把伞，但也可能你有太多的框架为一个第三方。

The OS vendor has an unusual situation due to the size and ubiquity of their system. Things that make sense at one scale often do not make sense at another. NSResponder is completely correct about that. The trade-offs are different when you're providing a complete, multi-thousand package environment that is the basis of every program written for the platform. But even Apple has only a handful of large umbrella frameworks, and they are always wrappers around libraries that they provide and control the version of. This is mostly to simplify the work of developers who would otherwise have to chase down dozens of libraries and frameworks to get something to compile. No third party has that situation, and so it is very rare that a third-party needs this solution. Asking your customer to link two libraries is completely different then asking them to link 20. If you're providing 20 frameworks that all work together and you control, then maybe you should use an umbrella, but also maybe you have too many frameworks for a third party.

我在这里讨论的大部分是OS X。在iOS上，这是一个非第三方问题。静态库必须永远不会链接其他静态库，因为肯定会发生冲突。

Most of my discussion here is in terms of OS X. On iOS it is a non-issue for third-parties. Static libraries must never link other static libraries due to the collisions that will certainly occur.

理论上，我在这里讨论的大多数问题是从根本上技术限制接头。链接器没有一个好的方法来管理库的多个版本，因此碰撞是一个严重的问题。 .NET程序集试图在这方面提供更多的灵活性。我不够熟悉.NET开发，以说明这是否成功。我对大型多组件系统的经验是，更简单，更不灵活的解决方案最适合大多数问题。 （但那时，草总是更绿的....）

In theory, most of the issues I've discussed here a fundamentally technical limitations of the linker. The linker doesn't have a good way to manage multiple versions of libraries and so collisions are a serious problem. .NET assemblies try to provide more flexibility around this. I'm not familiar enough with .NET development to say whether this has been successful or not. My experience with large multi-component systems is that simpler, less flexible solutions are best for most problems. (But then, the grass is always greener....)

这篇关于为什么不鼓励伞架？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！