I'm sometimes using a Singleton (to store data that is used by several different classes) in my projects and I'm thinking why not use my AppDeletage, since it's already a Singleton and easy to access. Is this a bad practice and if so, why?
我有时在我的项目中使用Singleton（存储由几个不同类使用的数据），我在想为什么不使用我的AppDeletage，因为它已经是Singleton并且易于访问。这是一种不好的做法，如果是这样，为什么？
5 个解决方案
#1
10
There is no right answer to this one. You'll get many opinions on this. I see no issue with using the AppDelegate, and I do it for all my apps:
这个没有正确的答案。你会对此有很多意见。我发现使用AppDelegate没有问题，我为我的所有应用做了这个：
- The delegate is practically mandatory for iPhone apps,
- 代表对于iPhone应用程序几乎是强制性的，
- it's there for the lifetime of the app;
- 这是应用程序的生命周期;
- and one can access it from anywhere in the program (although don't abuse that!).
- 并且可以从程序中的任何位置访问它（尽管不要滥用它！）。
One must remain vigilant though, so that code that doesn't necessarily have to be there, isn't there. You don't want your AppDelegate to become massive and unmaintainable.
但是，必须保持警惕，以便不一定必须存在的代码不存在。您不希望AppDelegate变得庞大且无法维护。
The question has been answered before on *:
之前在*上回答了这个问题：
Application Design and AppDelegate
应用程序设计和AppDelegate
The answers on that may help you also.
答案也可能对你有所帮助。
#2
4
AppDelegate should handle app behavior in states of launch, background entry and so on. You should not make it more complex as it's not a good design pattern. But you can always keep a reference to your dataStore class in your AppDelegate, and access it via AppDelegate. This way you abstract data storing from your AppDelegate but you will still be able to easily get to it.
AppDelegate应该在启动，后台条目等状态下处理应用程序行为。你不应该把它变得更复杂，因为它不是一个好的设计模式。但您始终可以在AppDelegate中保留对dataStore类的引用，并通过AppDelegate访问它。这样，您可以从AppDelegate中抽象存储数据，但您仍然可以轻松地访问它。
#3
3
I get a lot of guff for this, but for smallish data that has global relevance, I have no problem at all keeping in the App Delegate.
我对此感到非常愤怒，但对于具有全球相关性的小数据，我在App Delegate中完全没有问题。
Bigger pieces of data need a store that's out of memory (Core Data, the filesystem, SQLlite, or what have you).
更大的数据需要一个内存不足的存储（Core Data，文件系统，SQLlite或者你有什么）。
My very first app had a TON of data sloshing around (text in NSDictionaries, UIImages in various sizes, etc). I built a data management singleton to keep it all in one place and handle server requests for updates. It worked okay. If I knew then what I know now, I probably would have worked out a Core Data synchronization strategy instead.
我的第一个应用程序有一大堆数据晃动（NSDictionaries中的文本，各种大小的UIImages等）。我构建了一个数据管理单例，将其保存在一个位置，并处理服务器的更新请求。它运作正常。如果我知道我现在所知道的，我可能会制定一个核心数据同步策略。
#4
0
Well, in terms of data abstraction it may be a bit on the unsafe side, but i believe it is a handy place in the memory too. What you should do, may be to encapsulate the variables with accessor methods so that you have a place to do the concurrency related operations (if any)
好吧，就数据抽象而言，它可能有点不安全，但我相信它在内存中也是一个方便的地方。你应该做的，可能是用访问器方法封装变量，这样你就可以进行与并发相关的操作（如果有的话）
But if what you mean is passing objects from one UI class to another, then probably you should use something else, like setting member variables of one from the other, or use datastore etc.
但是，如果你的意思是将对象从一个UI类传递到另一个UI类，那么可能你应该使用其他东西，比如设置另一个的成员变量，或使用数据存储等。
#5
0
For little bits of controller code that are relevant to the entire app, I use the AppDelegate. If there's a sensible way to split off the code into a separate controller object then that would be preferable, as I've seen app delegates that have ballooned to unmanageable size.
对于与整个应用程序相关的少量控制器代码，我使用AppDelegate。如果有一种合理的方法将代码拆分成一个单独的控制器对象，那么这将是更可取的，因为我已经看到已经膨胀到无法管理的大小的应用程序代理。
It can also be a good way to 'singletonize' controller objects, without burning your bridges if you want later to have more than one of them.
它也可以是一种“单一化”控制器对象的好方法，如果你以后想要拥有多个控制器对象，则不需要烧掉它们。
I actually put a class method on the AppDelegate to access it, so I can do things like:
我实际上在AppDelegate上放了一个类方法来访问它，所以我可以这样做：
[[AppDelegate get].dataStore getRecordNumber:x] // or
[[AppDelegate get].server refreshData]
But I'm sure there are those that think this is bad design in a team setting.
但我确信有些人认为这在团队环境中是糟糕的设计。
#1
10
There is no right answer to this one. You'll get many opinions on this. I see no issue with using the AppDelegate, and I do it for all my apps:
这个没有正确的答案。你会对此有很多意见。我发现使用AppDelegate没有问题，我为我的所有应用做了这个：
- The delegate is practically mandatory for iPhone apps,
- 代表对于iPhone应用程序几乎是强制性的，
- it's there for the lifetime of the app;
- 这是应用程序的生命周期;
- and one can access it from anywhere in the program (although don't abuse that!).
- 并且可以从程序中的任何位置访问它（尽管不要滥用它！）。
One must remain vigilant though, so that code that doesn't necessarily have to be there, isn't there. You don't want your AppDelegate to become massive and unmaintainable.
但是，必须保持警惕，以便不一定必须存在的代码不存在。您不希望AppDelegate变得庞大且无法维护。
The question has been answered before on *:
之前在*上回答了这个问题：
Application Design and AppDelegate
应用程序设计和AppDelegate
The answers on that may help you also.
答案也可能对你有所帮助。
#2
4
AppDelegate should handle app behavior in states of launch, background entry and so on. You should not make it more complex as it's not a good design pattern. But you can always keep a reference to your dataStore class in your AppDelegate, and access it via AppDelegate. This way you abstract data storing from your AppDelegate but you will still be able to easily get to it.
AppDelegate应该在启动，后台条目等状态下处理应用程序行为。你不应该把它变得更复杂，因为它不是一个好的设计模式。但您始终可以在AppDelegate中保留对dataStore类的引用，并通过AppDelegate访问它。这样，您可以从AppDelegate中抽象存储数据，但您仍然可以轻松地访问它。
#3
3
I get a lot of guff for this, but for smallish data that has global relevance, I have no problem at all keeping in the App Delegate.
我对此感到非常愤怒，但对于具有全球相关性的小数据，我在App Delegate中完全没有问题。
Bigger pieces of data need a store that's out of memory (Core Data, the filesystem, SQLlite, or what have you).
更大的数据需要一个内存不足的存储（Core Data，文件系统，SQLlite或者你有什么）。
My very first app had a TON of data sloshing around (text in NSDictionaries, UIImages in various sizes, etc). I built a data management singleton to keep it all in one place and handle server requests for updates. It worked okay. If I knew then what I know now, I probably would have worked out a Core Data synchronization strategy instead.
我的第一个应用程序有一大堆数据晃动（NSDictionaries中的文本，各种大小的UIImages等）。我构建了一个数据管理单例，将其保存在一个位置，并处理服务器的更新请求。它运作正常。如果我知道我现在所知道的，我可能会制定一个核心数据同步策略。
#4
0
Well, in terms of data abstraction it may be a bit on the unsafe side, but i believe it is a handy place in the memory too. What you should do, may be to encapsulate the variables with accessor methods so that you have a place to do the concurrency related operations (if any)
好吧，就数据抽象而言，它可能有点不安全，但我相信它在内存中也是一个方便的地方。你应该做的，可能是用访问器方法封装变量，这样你就可以进行与并发相关的操作（如果有的话）
But if what you mean is passing objects from one UI class to another, then probably you should use something else, like setting member variables of one from the other, or use datastore etc.
但是，如果你的意思是将对象从一个UI类传递到另一个UI类，那么可能你应该使用其他东西，比如设置另一个的成员变量，或使用数据存储等。
#5
0
For little bits of controller code that are relevant to the entire app, I use the AppDelegate. If there's a sensible way to split off the code into a separate controller object then that would be preferable, as I've seen app delegates that have ballooned to unmanageable size.
对于与整个应用程序相关的少量控制器代码，我使用AppDelegate。如果有一种合理的方法将代码拆分成一个单独的控制器对象，那么这将是更可取的，因为我已经看到已经膨胀到无法管理的大小的应用程序代理。
It can also be a good way to 'singletonize' controller objects, without burning your bridges if you want later to have more than one of them.
它也可以是一种“单一化”控制器对象的好方法，如果你以后想要拥有多个控制器对象，则不需要烧掉它们。
I actually put a class method on the AppDelegate to access it, so I can do things like:
我实际上在AppDelegate上放了一个类方法来访问它，所以我可以这样做：
[[AppDelegate get].dataStore getRecordNumber:x] // or
[[AppDelegate get].server refreshData]
But I'm sure there are those that think this is bad design in a team setting.
但我确信有些人认为这在团队环境中是糟糕的设计。