为什么伞形框架不鼓励？

Question

我想分发框架A.框架A依赖于框架B.我希望我的框架的用户只需要包含框架A，但仍然具有对框架B的编程访问。

Apple一直使用“Umbrella Frameworks”的概念来做这件事，但是文档中有这个主题：

  

不要创建伞框架

     

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

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

Answer 1

如果您是所有相关框架的唯一分发者，那么伞框架才有意义，您将把所有框架打包在一起作为单个版本化的包，它们将一起升级。如果这是你的情况，那很好，但这是一个非常不寻常的情况。在可可开发领域，除了苹果之外的任何人都处于这种情况下是非常不寻常的。

首先，如果您是给定框架的唯一分发者，则伞形框架才有意义。例如，假设您希望将libcurl作为伞形框架的一部分。现在其他一些打包者也希望将libcurl作为其伞形框架的一部分。现在我们有一个链接时碰撞，可能导致链接错误或更糟糕的未定义的运行时行为。我自己也追了这些。他们非常不愉快。避免这种情况的唯一方法是每个框架/库只有一个版本。伞框架鼓励相反。

即使您只是将自己的代码分解为子代码，这意味着其他供应商可能会在自己的框架中使用您的子框架，从而导致同样的问题。请记住，如果你说作为第三方使用伞形框架你没问题，那么对其他供应商来说也没问题。

对于第二点，如果您控制所有子框架的版本控制，则伞形框架才有意义。根据我的经验，尝试修补一个相互依赖的框架集几乎总是一个灾难。

由于系统的规模和普遍性，操作系统供应商的情况很不寻常。在一个尺度上有意义的事情往往在另一个尺度上没有意义。 NSResponder对此完全正确。当您提供一个完整的，数千个包装环境时，权衡是不同的，这是为平台编写的每个程序的基础。但即便是苹果公司也只有少数大型伞形框架，它们总是围绕着它们提供和控制版本的库的包装。这主要是为了简化开发人员的工作，否则他们不得不追逐数十个库和框架来编译。没有第三方有这种情况，因此第三方需要这种解决方案的情况非常罕见。要求你的客户链接两个库是完全不同的，然后要求他们链接20.如果你提供20个框架，所有工作在一起，你控制，那么也许你应该使用一把伞，但也许你有太多的框架第三方。

我在这里讨论的大多数是关于OS X.在iOS上，对于第三方来说这不是问题。由于肯定会发生冲突，静态库绝不能链接其他静态库。

理论上，我在这里讨论的大多数问题都是链接器的基本技术限制。链接器没有很好的方法来管理多个版本的库，因此冲突是一个严重的问题。 .NET程序集试图为此提供更多灵活性。我对.NET开发不够熟悉，不知道这是否成功。我对大型多组件系统的经验是，对于大多数问题来说，更简单，灵活性更低的解决方案是最好的。 （但那时，草总是更环保......）

Answer 2

一个问题是框架B的版本现在与框架A的版本相关联。这可能是您在某些情况下所需要的而不是其他情况。如果框架B很可能被一个也想要使用框架A的应用程序独立使用，那么应用程序可能会发现自己处于A中包含的B版本不是它需要或想要的版本的情况。

框架B是一个应用程序可以独立于A使用的框架吗？如果是这样，那么您可能会遇到这种情况。如果B是在A之外不可用的框架，那么您不应该遇到这种情况。

Answer 3

在Apple的案例中，他们提供了大量的代码，而这些子框架通常是单独修改的。如果您要提供几个框架，那么您可能希望继续构建一个伞形框架。如果没有，你可能不需要麻烦。