MVCS-模型视图控制器存储

我最近决定开始学习iOS开发，为此，我一直在阅读iOS编程：The Big Nerd Ranch Guide。在这本书中，作者描述了一种设计模式MVCS-Model-View-Controller-Store，其基本思想是，由于许多应用程序使用多个外部数据源，因此将请求逻辑保留在控制器中可能会变得非常混乱。建议将所有请求逻辑从控制器中移出并移到单独的对象中。

简而言之，引用这本书

Model-View-Controller-Store将请求逻辑放入一个单独的对象中，我们将此对象称为存储（图28.4）。使用存储对象可以最大程度地减少冗余代码，并简化获取和保存数据的代码。最重要的是，它把处理外部资源的逻辑转移到了一个清晰且目标明确的类中。这使代码更易于理解，也易于维护和调试，并与团队中的其他程序员共享。

和

关于异步存储的一个很酷的事情是，即使很多对象在处理一个请求上做了很多工作，但请求的流及其响应却在控制器中的一个位置。这给我们带来了易于阅读且易于修改的代码的优势。

我想了解更多关于这种模式的信息，并想看看其他人可能要说些什么，但是在网上搜索时，我唯一能找到的参考是同一本书（这种模式也许以其他名字叫吗？）。

在我看来，作者的逻辑似乎很有意义，而且似乎是常规MVC模式的逻辑扩展，但这也许是因为我实际上对MVC模式没有太多的经验（除了涉足iOS开发之外，我还拥有带有骨干 .js的已使用MVV （也就是说，如果您将其视为MVC）。

我希望也许有更多经验的人可以阐明我所缺少的MVCS模式是否存在任何明显的缺陷/问题。

在MVCS设计模式的情况下，“存储”往往倾向于存储逻辑。对于iOS，这通常是Core Data实现。如果在Xcode中创建一个由Core Data支持的模板，您将在AppDelegate类中看到该设计模式的“存储”方面。

为了使它更上一层楼，我经常会创建一个单例管理器类，该类负责设置Core Data堆栈，并处理与该堆栈有关的所有获取/保存操作。正如您提到的引言所说，这不仅使调用这些方法非常容易，而且在需要时可以轻松地对其进行调整，这与在不同的视图控制器中各处保存/获取调用相反。

但是，“存储”范例并不限于核心数据。您的商店可能只是一个Web服务。也许您有一个与Facebook，Twitter，Yelp或其他基于REST的API交互的类。我发现（并且类似地遵循这种趋势）这些类型的类也被称为Manager。他们实际上是在管理所有内部细节，以便您的其他类可以准确地放入或取出所需的内容。

就此设计模式的明显缺陷或问题而言……与任何设计模式一样，最明显的问题是确保您以与范例相适应的方式来设置项目。尤其是对于您不熟悉的设计模式而言，这有时可能是最难的部分。将“存储”逻辑分解为自己的类的好处是，它使代码的可维护性更加容易。

在这种情况下，“存储”听起来非常像是存储库或服务。在这种情况下，这是一种非常常见的模式。 缺陷/问题将随您的实现方式和问题域而变化。

从总体上看，这本书听起来像是在使用“存储”来表示业务逻辑级别+用来处理可能是应用程序一部分或可能不是应用程序一部分数据的数据检索逻辑级别。

例如，将twitter api包装在“商店”中是分隔该逻辑的一种好方法。

经过进一步思考，
使用MVC的定义（我认为这很不错），“商店”实际上是模型的子集。它是对MVC的扩展还是数据检索模式之间的区别并不是非常有用。它们最终看起来像相同的代码。

最重要的是，我认为遵循他们的建议就可以了（总体上听起来不错）。