将AppDelegate用作Singleton是不好的做法吗？

Question

我有时在我的项目中使用Singleton（存储由几个不同类使用的数据），我在想为什么不使用我的AppDeletage，因为它已经是Singleton并且易于访问。这是一个不好的做法，如果是这样，为什么？

Answer 1

这个没有正确的答案。你会对此有很多意见。我发现使用AppDelegate没有问题，我为所有应用程序都做了这个：

• iPhone应用程序的代表实际上是强制性的，
• 它适用于应用程序的生命周期;
• 并且可以从程序中的任何位置访问它（尽管不要滥用它！）。

但是必须保持警惕，因此不一定必须存在的代码不存在。您不希望AppDelegate变得庞大且无法维护。

之前已经在StackOverflow上回答了这个问题：

Application Design and AppDelegate

答案也可能对你有帮助。

Answer 2

AppDelegate应该在启动，后台条目等状态下处理应用程序行为。你不应该把它变得更复杂，因为它不是一个好的设计模式。但是，您始终可以在AppDelegate中保留对dataStore类的引用，并通过AppDelegate访问它。这样，您可以从AppDelegate中抽象存储数据，但您仍然可以轻松地获取它。

Answer 3

我为此感到非常愤怒，但对于具有全球相关性的小数据，我在App Delegate中完全没有问题。

更大的数据需要一个内存不足的存储（Core Data，文件系统，SQLlite或者你有什么）。

我的第一个应用程序有一大堆数据晃动（NSDictionaries中的文本，各种大小的UIImages等）。我构建了一个数据管理单例，将它们保存在一个地方，并处理服务器的更新请求。它工作好的。如果我知道我现在所知道的，我可能会改为制定核心数据同步策略。

Answer 4

嗯，就数据抽象而言，它可能有点不安全，但我相信它在内存中也是一个方便的地方。你应该做的，可能是使用访问器方法封装变量，这样你就可以进行与并发相关的操作（如果有的话）

但是如果你的意思是将对象从一个UI类传递到另一个UI类，那么你可能应该使用其他东西，比如设置另一个的成员变量，或使用数据存储等。

Answer 5

对于与整个应用程序相关的一小部分控制器代码，我使用AppDelegate。如果有一种明智的方法将代码拆分成一个单独的控制器对象，那么这将是更可取的，因为我已经看到已经膨胀到难以管理的大小的应用程序代理。

它也可以是一种“单一化”控制器对象的好方法，如果你以后想要有多个控制器对象，可以不烧掉它们。

我实际上在AppDelegate上放了一个类方法来访问它，所以我可以这样做：

[[AppDelegate get].dataStore getRecordNumber:x] // or
[[AppDelegate get].server refreshData]

但我确信有些人认为这在团队环境中是糟糕的设计。