【发布时间】：2011-07-06 12:58:57
【问题描述】：
我正在创建一个AppDelegate 的对象并在整个程序中使用它，并且我已经声明了所有setter 和getter，并且还在其中插入、选择、删除、更新数据库查询。
我想问这样做是否是一个好习惯， 如果是，那么如何，如果不是，那么为什么这不是一个好习惯？
我希望我的问题很清楚，如果您有任何问题，请提出相关问题。
【问题讨论】：
标签： iphone singleton uiapplicationdelegate
【发布时间】：2011-07-06 12:58:57
【问题描述】：
一切都与复杂性和您的感受有关。你一定喜欢你的解决方案;-)
我显然是用另一种方式来做这件事的——我有单例，它确实处理了我所有常见的数据库事情。我试图让应用程序委托尽可能简单。更适合代码共享等。
【讨论】：
-
如果其他人使用相同的代码，他们以后必须喜欢他的解决方案:)
我认为最好的方法是创建一个全局单例类，而不是在 Appdelegate 中处理。
在那里声明所有的 setter 和 getter，并在项目中使用单例对象句柄。看这个链接如何创建singleton class
对于数据库，创建一个 DataAccessLayerClass。每当您要执行任何查询时，请访问此类。此类方法应将输入作为您的数据，并将创建查询并执行该查询并返回数据。
【讨论】：
-
你提到的单例模式——一个对象具有“烘焙”的单例性质——是相当严格的。如果您以后想要拥有两个数据库管理器对象（因为您连接到两个数据库）怎么办？如果您编写的测试需要多个实例来实现测试，该怎么办？提供某种类型的工厂来分发配置的共享单例实例更加灵活。只是我的意见。
-
还有另一个问题：好的设计通常涉及将配置信息传递到数据库管理器（或其他），而不是配置自身（再次出于测试等原因）。但是，如果您的所有代码都向单例对象本身询问其共享实例，这将变得很棘手，因为您对 getInstance 的所有调用都必须传入配置信息以备不时之需。
将您的 AppDelegate 变成一个包含一百万个方法和属性的“大泥球”并不是一个好策略（尽管它可能很诱人）。
一种更好、更面向对象的方法，将部分功能划分为设计良好的对象——例如，您可能有一个处理所有数据库交互的类 DatabaseManager。然后，您可能有一些需要 DatabaseManager 的应用程序向应用程序委托实例请求对 DatabaseManager 的引用。
或者，您可以将对 DatabaseManager 的引用传递给需要它的应用程序部分。然而，最后一种方法确实会导致更多的“接口污染”，您必须在很多地方修改接口才能传入 DatabaseManager。
另一种选择是有效地使您的 DatabaseManager 本身成为一个“单例”——通过类上的类方法访问它的实例。以这种方式工作的单例通常不受欢迎，通常是有充分理由的（使测试更难，诸如此类）。我倾向于避免将对象的“单例”性质直接融入对象中——如果我需要这种东西，我更喜欢有一个已知的访问点（如果你喜欢的话，一种“工厂”），你可以去获取一个共享实例。
【讨论】：