为什么不鼓励使用伞式框架? [英] 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 框架"的概念来执行此操作，但文档中有此主题:

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

不要创建伞形框架

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

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.

为什么不鼓励这种方法?是什么使它成为 Apple 的相互依赖框架问题的一个很好的解决方案，但对我的却不是?

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

推荐答案

Umbrella 框架只有在您是所有相关框架的唯一经销商时才有意义，并且您将所有框架打包在一起作为一个单独的版本包一起升级.如果这是你的情况，那很好，但这是一个非常不寻常的情况.在 Cocoa 开发领域，除了 Apple 之外的任何人都处于这种情况是非常不寻常的.

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 作为其伞式框架的一部分.现在我们有一个链接时冲突，它可能导致链接错误或更糟糕的未定义的运行时行为.我自己追过这些.他们非常不愉快.避免这种情况的唯一方法是每个框架/库只有一个版本.Umbrella 框架鼓励相反的情况.

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 是完全正确的.当您提供一个完整的、数千个程序包的环境时，权衡是不同的，该环境是为平台编写的每个程序的基础.但即使是 Apple 也只有少数大型框架框架，而且它们总是围绕它们提供并控制其版本的库进行包装.这主要是为了简化开发人员的工作，否则他们将不得不寻找数十个库和框架来编译.没有第三方有这种情况，因此第三方需要此解决方案的情况非常罕见.要求您的客户链接两个库与要求他们链接 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屋！