Tag: Mvc
iOS开发中的传统MVC和MVC
简短明了，让我们直接看一下传统MVC和iOS中MVC的图表。 在传统的MVC中，视图对象可以通过采用“主观观察者”设计模式来注册模型对象的状态更改事件，一旦视图对象感兴趣的模型对象的状态更改，视图对象就会得到通知。 在iOS中，我们应该努力避免视图对象与模型之间的直接交互。 视图对象应始终通过控制器对象来了解模型对象中的更改。 好吧，就是这样。 以上是我想在本文中谈论的主要内容，但是如果您想获得更多详细信息，可以继续阅读。 Model-View-Controller是一种非常高级的体系结构设计模式，它认为存在三种类型的对象：模型对象，视图对象和控制器对象。 它定义了这些类型的对象在应用程序中扮演的角色及其通信线路。 模型是模式的核心组成部分。 它代表特殊的知识和专长，并根据问题域表达应用程序的行为。 它们保存应用程序的数据，并定义处理该数据的逻辑。 设计良好的MVC应用程序将其所有重要数据封装在模型对象中。 一旦将数据加载到应用程序中，任何属于应用程序持久状态的数据（无论该持久状态存储在文件还是数据库中）都应驻留在模型对象中。 因为它们代表与特定问题领域相关的知识和专长，所以它们倾向于可重用。 理想情况下，模型对象与用于呈现和编辑它的用户界面没有显式连接。 例如，如果您有一个代表一个人的模型对象（例如您正在写通讯录），则可能要存储生日。 存储在您的Person模型对象中是一件好事。 但是，存储日期格式字符串或其他有关如何显示该日期的信息可能更好。 视图对象知道如何显示，并且可能允许用户编辑应用程序模型中的数据。 该视图不应负责存储其显示的数据。 （当然，这并不意味着视图从不实际存储其显示的数据。出于性能原因，视图可以缓存数据或执行类似的操作）。 视图对象可以负责仅显示模型对象的一部分，整个模型对象甚至许多不同的模型对象。 视图有很多不同的种类。 视图对象倾向于可重用和可配置，并且它们在应用程序之间提供一致性。 在iOS中，UIKit框架定义了大量视图对象，并在Interface Builder库中提供了许多视图对象。 通过重用UIKit的视图对象（例如UIButton对象），可以确保应用程序中的按钮的行为与其他任何iOS应用程序中的按钮一样，从而确保了各个应用程序在外观和行为上的高度一致性。 控制器对象充当应用程序的视图对象与其模型对象之间的中介。 控制器通常负责确保视图可以访问他们需要显示的模型对象，并充当视图了解模型更改的渠道。 控制器对象还可以为应用程序执行设置和协调任务，并管理其他对象的生命周期。 在iOS MVC设计中，当用户输入值或通过视图对象指示选择时，该值或选择将传达给控制器对象。 控制器对象可能以某种特定于应用程序的方式解释用户输入，然后要么告诉模型对象如何处理此输入（例如，“添加新值”或“删除当前记录”），要么可能具有模型对象在其属性之一中反映了更改的值。 基于相同的用户输入，某些控制器对象可能还会告诉视图对象更改其外观或行为的某个方面，例如告诉按钮禁用自身。 相反，当模型对象发生更改时（例如，访问新的数据源），模型对象通常会将更改传达给控制器对象，然后控制器对象请求一个或多个视图对象进行相应的更新。 除了将应用程序分为三类之外，模型-视图-控制器设计还定义了它们之间的交互。 模型存储数据，该数据根据来自控制器的命令检索并显示在视图中。 视图基于模型的更改为用户生成新的输出。 它还可以向其关联的视图发送命令以更改视图的模型表示形式 以下准则适用于应用程序设计中的模型-视图-控制器注意事项： 设计良好的MVC应用程序的目标应该是使用（理论上至少）可重用的尽可能多的对象。 特别是，视图对象和模型对象应具有高度可重用性。 特定于应用程序的行为通常尽可能地集中在控制器对象中。 尽管可以使视图直接观察模型以检测状态变化，但是最好不要这样做。 视图对象应始终通过中介控制器对象来了解模型对象中的更改。 努力限制应用程序类中的代码依赖性。 一个类对另一个类的依赖性越大，可重用性就越差。 具体建议因所涉及的两个类别的MVC角色而异： —视图类不应依赖于模型类（尽管某些自定义视图可能不可避免）。 —除其他模型类外，模型类不应依赖任何其他内容。
为什么我爱Apple MVC
声明：我仍在学习iOS编程，因此请将此作为学习笔记而不是教程。 干杯! MVC摇滚。 不严重，这是我见过的最干净的架构。 让我们看一下这张图： 现在告诉我这种三组分结构如何变得更清洁。 也许MVVM？ 它也仅由3个组件组成。 但是，等等，现在我们有了另一层称为binding ，而不是普通的事件驱动的MVC体系结构 。 是的，绑定有其优点，但是恕我直言，它不必要地使事件流难以理解。 因此，它是比Apple MVC更复杂的体系结构。 我认为人们之所以如此讨厌Apple MVC，是因为用它编写大型视图控制器很容易。 但是首先， 大规模视图控制器有什么不好？ 我的意思是，如果视图控制器职责明确且结构合理，因此非常易于维护，那么编写大型视图控制器是一种不好的做法？ 对我来说，更少的代码并不等于更好的代码。 易于理解对代码而言更为重要。 可以在一种方法中配置表视图（可能是viewDidLoad() ），并带有一些UIKit closurising扩展，并使代码比将经典的委托和数据源协议应用于视图控制器本身要少得多，但实际上，维护该视图非常容易具有协议扩展的代码，而不是单一方法中的一堆多层代码。 想一想。 委托扩展是这样的： extension MyViewController: UITableViewDelegate { // Protocol implementations } 它基本上意味着MyViewController在说“我可以管理UITableView ，这就是我要管理的方式”。 换句话说， 所有与 UITableView 相关的代码都在此extension中 。 这真太了不起了。 即使您的视图控制器具有数千行代码，您也可以轻松地在此扩展中查找任何表视图问题。 对我来说，如果视图控制器过于复杂，可能是因为 一个视图控制器的职责过多。 该方法设计不良。 视图控制器中存储的属性过多。 那么如何改进呢？ 确定何时使用视图控制器（而不是仅使用视图） 通常，人们认为视图控制器代表一个场景 ，因此仅在出现新场景时才应使用视图控制器。 这不是真的。 每当场景过于复杂时，都应将其分解为几个子场景-或子视图控制器。 像UINavigationController一样。 它的职责仅是管理其子视图控制器的转换 […]
现代MVC
当iPhone仅是第三部时，我在Apple Developer门户上有关iOS编程的第一篇教程的开头看到了此图： （仍然存在类似的文章，并且图表在那里：Cocoa核心能力。模型-视图-控制器） 该图展示了基本的iOS体系结构模式MVC 。 10年前，我以一种非常简单的方式理解了该图： UIView，UIScrollView或UITableView是该图上的视图 。 作为开发人员，我将它们安排在Interface Builder中的一个场景上，并将它们与我的源代码（在视图控制器中定义的出口和动作）绑定在一起。 最后一个正是MVC图中的控制器 。 我的应用程序将用户数据存储在例如文本文件中，或者在更复杂的情况下通过Core Data存储。 图表中的模型是允许访问此数据的类。 要添加的另一件事： 模型中没有业务逻辑代码，该模型不与视图通信。 视图控制器负责创建所有视图和模型，并在它们之间进行通信。 这样简单的系统的行为很明显：用户与视图进行交互，并且他的动作被传递给视图控制器。 最后一个执行计算，更改其自己的状态，并且此状态反映在视图中。 如果用户操作需要更改模型 ，则视图控制器会调用该模型进行更改。 如果模型发生更改，则会将该更改通知给视图控制器 。 视图控制器就是其中之一，它可以更新视图 。 这是对这种基本模式的简化甚至天真的理解。 但是它允许开发简单的应用程序，例如计算器或绘画工具。 我想展示一种开发和维护更复杂的应用程序的方法。 首先，让我们变换上面的图并以分层样式绘制它。 它使人想起大学时代熟悉的常见应用程序架构图： 该层是一个非常时髦的术语。 分层样式无处不在，包括应用程序体系结构。 我当时的所有项目都从该图开始，具有三个应用程序层：用户界面，业务逻辑和数据。 所有应用程序对象都属于这些层之一。 数据层和用户界面不进行通信，而是通过业务逻辑进行通信。 让我们复杂化该分层MVC图。 View-controller创建模型并在发生更改时调用它，并在图中显示为箭头。 箭头从视图控制器到视图 — 视图控制器创建所有视图 ，并在其状态或模型发生更改时对其进行更新。 该模型对视图控制器一无所知，如果模型发生更改，它会发布有关该视图的通知，或者更常见的是， 视图控制器会观察到模型更改。 它在运行时发生，我更喜欢使用虚线从模型到视图控制器绘制此箭头。 虚线箭头还应该显示从视图到视图控制器的连接 ：用户在运行时与视图进行交互，但是视图不直接调用视图控制器 ， 视图不知道视图控制器界面并通过Target-Action Design模式将用户操作传递给视图控制器 。 这是MVC的最简单或理想形式，适用于仅由一个视图控制器构造的小型应用程序。 让我们再添加一个view-controller 。 例如，单击视图控制器中的按钮（上面带有一个视图 […]
Sushi解释模型-视图-控制器
了解MVC模式和辣蛋黄酱 模型-视图-控制器（MVC）模式将Web应用程序的输入，处理和输出分开，并以三个易于理解的部分组织交互：模型，视图和控制器。 …如果我们像寿司店那样想的话，甚至更容易理解。 我进入章鱼DTLA，这是USC学生的便宜寿司场所和赛前场所。 我坐在寿司吧，看厨师马克，点菜。 “请给我一个红色的龙卷。” 我是用户 ， 我的寿司订单是请求。 对我来说，我的订单是美味的金枪鱼和鳄梨奶油（见上图）。 当我说出我的订单时，对于像马克这样有经验的厨师，他知道该做什么。 马克的大脑是控制者。 他认为滚动是一系列步骤： 煮饭。 将金枪鱼，鳄梨和黄瓜切成1厘米见方的棍棒。 将寿司从里到外滚动，将食材和辛辣的蛋黄酱作为馅料。 切卷。 撒上飞鱼子，炸洋葱和黑芝麻。 对Mark来说，此过程类似于制作加州卷或费城卷，但根据每个订单的独特成分而有所不同。 如果我点炸鸡怎么办？ 马克在值班。 他不能把自己的职位留在寿司吧后面。 他只能使用我们提供给他的工具和资源。 这个有限的工具集就是模型，在我们的示例中包括寿司刀，竹辊，他的手，芥末，鱼的种类，调味料等。完成的卷就是视图。 视图由模型的有限选项构建而成，并通过控制器进行排列和传输。 让我们退后一步，从产品管理的角度思考为什么这种MVC模式很棒。 假设您的客户想要重新设计您的应用程序。 如果您将视图和逻辑结合在一起，则重新蒙皮很烂。 确实，主要优点是MVC使模块化的模型类无需修改即可重用。 MVC体系结构将关注点分开，并允许独立进行推理。 这是创建用户界面的非常有效的创新方法。 通过创建彼此独立的组件，开发人员可以快速轻松地在其他应用程序中重用，并进行修改而不会影响整个模型。 TL; DR： MVC或模型视图控制器是一种架构模式，通常以流行的Web框架的形式使用。 模型-模型代表知识。 它们可以是单个对象，也可以是对象的结构。 它们构造和存储数据，然后根据控制器的命令进行准备和检索。 在电话应用程序中，模型对象可以是游戏中的角色，通讯录中的联系人。 用数据结构的术语来说，模型就是图。 视图-思考UI。 用户可以看到视图，并根据他们的操作显示数据。 它与单个DOM节点相对应，并且可以由子视图组成。 用数据结构的术语来说，视图就是树。 控制器-决定用户的视图输入是什么，并将这些命令发送到模型，并将模型数据提供给视图和系统。 解释用户操作，例如单击按钮。 有时，基于框架，可以与视图结合（例如在Backbone.js中）。
什么是Model View Controller设计模式？
什么是模型视图控制器模式？ 模型视图控制器是一种用于Web开发服务（例如应用程序）的软件模式。 与语言无关。 它是Web开发中使用最广泛的范例之一。 MVC体系结构由哪些组件组成？ 模型 模型是模式中的主要组件，它管理应用程序的数据，逻辑和规则。 该模型将数据构造并存储在数据库中，并且受控制器命令的约束。 视图 这是屏幕和/或用户界面（UX）形式的数据输出表示。 您可以想象这是您在应用程序中用于规定视图行为的DOM或文档对象模型。 控制者 这将接受输入并发送命令以发送到模型，然后模型将视图输出给应用程序的用户。 在Laravel应用程序中运行MVC 如果基于Laravel应用程序创建新的Web开发服务，则要考虑的最重要的事情之一就是模型。 模特第一 这通常是首先以表的形式创建的东西。 该表已创建，并且由组成模型的各个字段组成。 控制器秒 接下来，我们通常创建一个控制器。 这是用于将数据转换为视图的处理实体。 查看第三 最后，我们创建将用于服务的视图； 说; 一个Web开发服务应用程序，然后在Laravel应用程序的resources / views目录下创建它们。 下面的图表显示了实际的MVC模式： 重要的是要了解MVC设计模式允许组件在同一环境中松散耦合。 这使您可以创建易于修改的单独的可重用组件。 从长远来看，这意味着开发应用程序所花费的时间更快，更高效。 尤其是考虑到客户需要更改MVC模式的事实。 进行这些修改或更改模型等不会很快。 模型视图控制器概念是计算机编程的基本原则之一，当您是技术领域的新手并试图通过提供各种Web开发服务和项目谋生时，这是一个非常有用的范例。 重要的是要知道如何将模型视图控制器概念映射到您自己的项目中。 原因是它从概念上帮助您增强了对松耦合组件通信方式的理解和认识。
带有MVC的iOS Tableview
如何使其清晰并享受您的代码 如果您构建iOS项目，您已经知道这个事实：最常用的组件之一是UITableView 。 如果您尚未构建任何项目，您仍然可以在许多流行的iOS应用中看到UITableView ：YouTube，Facebook，Twitter，Medium，大多数Messenger应用等。基本上，每次需要显示动态数量的在同一视图上的数据对象，请使用UITableView 。 另一个基本组件是CollectionView，我个人更喜欢使用它，因为它更灵活。 稍后我将发表另一篇有关CollectionView的文章。 因此，您想将UITableView添加到您的项目。 一种明显的方法是使用具有内置UITableView的UITableViewController 。 它可以通过简单的设置工作，您只需要添加数据数组并创建一个单元格即可。 它看起来很简单，并且可以按照我们需要的方式工作，除了以下几点： UITableViewController代码变得超长。 并且它打破了MVC模式。 什么是MVC？为什么我们需要考虑一下？ 您可以查看这篇文章，其中对所有iOS体系结构模式都有很好的解释。 您不想处理所有这些模式吗？ 无论如何，您可能仍想拆分您的一千行长的UITableViewController。 在上一篇文章中，我描述了将数据从模型传递到控制器的三种方法。 在本文中，我将使用委派方法向您介绍处理tableViews的方法。 这种方法使代码看起来非常整洁，模块化且可重用。 我们将不使用一个UITableViewController ，而是将其拆分为多个类： DRHTableViewController ：我们将其设为 UIViewController的子类，并添加UITableView作为子视图 DRHTableViewCell ： UITableViewCell的子类 DRHTableViewDataModel ：它将使用委托进行API调用，创建数据并将数据返回给DRHTableViewController DRHTableViewDataModelModelItem ：一个简单的类，将保存所有数据，这些数据将显示在DRHTableViewCell中 。 让我们从UITableViewCell开始。 第1部分：TableViewCell 从一个名为“单视图应用程序”的新项目开始，并删除默认的ViewController.swift和Main.storyboard文件。 我们将逐步创建所有需要的文件。 首先，创建一个UITableViewCell子类。 如果要使用XIB ，请选中“也创建XIB文件”。 在此示例中，我们将复制中型主页的简化版本。 因此，我们将需要添加以下子视图： 头像图片 名称标签 日期标签 文章标题 文章预览 以所需的方式应用“自动布局”，因为单元格设计不会影响我们在本教程中所做的任何事情。 为每个子视图创建一个出口。 在您的DRHTableViewCell.swift中，您将具有类似以下内容： 类DRHTableViewCell：UITableViewCell { @IBOutlet弱var […]
协调员，面向协议的编程和MVVM； Swift的防弹架构
MVVM或模型，视图，视图模型的起源来自于2005年发布此文章的两名Microsoft开发人员： 用于构建WPF应用程序的Model / View / ViewModel模式简介 它修复了标准MVC或模型View Controller范例中的一些叙述空白，特别是消除了产生View Controller的副作用： 1）比他们应该了解的多得多 2）成为应用程序逻辑的重点 3）比他们指定的任务更加负责 View Controller变成了庞大的文件，难以维护，不是模块化且难以重新利用。 因此进入视图模型。 太从作者的角度出发 该术语的意思是“视图的模型”，可以被认为是视图的抽象，但是它也提供了视图可以用于数据绑定的模型的特殊化。 在后一个角色中，ViewModel包含将模型类型转换为视图类型的数据转换器，并且包含视图可用于与模型交互的命令。 通过改变逻辑和数据并将其放置在VM中，您可以在整个应用程序中重用视图的数据。 好吧，以后再深入。 面向协议的程序设计 。 苹果公司（源）一直在积极推动这个概念，我可以写一篇有关该主题的文章，但是要取得的成果以及我们将如何使用它非常简单。 为了创建具有严格功能限制的高度可重用的View模型，我们将创建协议来告知我们如何创建模型。 一旦有了该模型，我们将创建存储所有信息的视图模型，并将其传递给我们的视图控制器。 协调员 。 据我所知， 协调员一词是Soroush Khanlou在2015年创造的。我看到他的作品有很多风味，而其他出色的开发人员对此主题的看法也是如此。 如果想要裸露骨头，请严格按照POP方法检查Niels Van Hoorn，但到目前为止，我最喜欢的是AleksandarVacić。 协调器完全解决了UI层中的数据流。 它们不保存也不包含任何类型的应用程序数据-他们的主要关注点是将数据从中间件改组到前端UI。 他们做什么： 创建VC的实例 显示或隐藏VC 配置VC（设置DI属性） 加： 接收来自VC的数据请求 将请求路由到中间件 将结果路由回VC 他对协调器进行了更进一步的更新，进一步巩固了它们作为视图控制器和模型通信者的演示者的地位。 如果您查看Navigation Coordinator则它是UINavigationController子类。 协调员应通过其创建和管理的活动来命名，并应为包含这些活动的UI的VC呈现并触发信息的创建。 今天，我们将创建一个简单的登录应用程序。 具有LoginViewController ， SetupAccountViewController和ForgotPasswordViewController一个。 这些都是与用户的帐户信息和身份验证交互的叙述，并且从这些视图控制器馈入和处理的数据非常相似： 1）有些表格可以接受用户数据 2）然后需要验证和处理此数据 3）如果数据未经验证，则需要通知用户其信息不正确 […]
MVC分解原理
iOS社区一直在寻找一种统一的架构来统治一切。 不幸的是没有。 为什么我要写这个。 我在专业项目上使用了MVC ， MVVM ， MVP ， VIPER等各种架构。 然后，我在寻找再次创建健壮的应用程序的正确方法。 有一天，我看到了由Guilherme Rambo创建的这个很酷的网站。 然后我开始思考，也许问题不在于架构。 也许我们的观点是问题所在。 因此，对于下一个项目，我决定选择MVC 。 在这篇文章中，您将了解这种方法。 问题 有关WMVC（错误的MVC）的主要问题是职责分配不平衡。 控制器几乎可以执行所有操作。 联网 资料解析 商业逻辑 动画制作 布置视图 用数据更新视图 响应用户输入 导航 因此，它很难测试，难以维护，难以修复。 UIViewController不是屏幕。 这是一个组成部分。 解 您可以在一个屏幕中使用许多视图控制器。 每个视图控制器都应承担自己的责任。 假设您从服务器加载数据并在屏幕上显示加载状态，然后响应出现，如果您的网络请求失败（总是失败），则在屏幕上显示数据状态或错误状态。 所有这些过程可能由一个视图控制器负责。 我们可以称之为StateViewController。 该视图控制器仅代表三种可能的状态。 您可以阅读John Sundell的这篇文章，以了解如何实现状态视图控制器。 当您需要针对不同屏幕的某些功能时，它非常简单，可以节省大量时间。 例 让我们来看一个例子。 我想创建一个Netflix细节场景。 我将场景分为如下所示的较小部分。 当然这是一个演示，我只想展示如何在屏幕上分解为较小的组件。 DetailViewController应该能够由其他视图控制器组成。 像HeaderViewController ， DescriptionViewController ， ActionsViewController等一样。这将提供容易的错误修复， 毫不费力地添加新功能，并且为大型控制器编写单元测试比大型视图控制器容易得多。 DismissViewController的责任是显示关闭按钮和火灾关闭事件。 […]
软件构架：MVC设计模式
软件体系结构是关于做出基本的结构选择，一旦实施，更改成本很高。 每个软件开发项目都经历多个阶段：概念，设计，开发，测试等等。 作为一名初级开发人员，对我而言显而易见的是，在开始编写任何代码之前，至关重要的是，全面规划应用程序的体系结构基础，以确保您的应用程序从一开始就具有模块化，稳定和可扩展的特性。 架构设计有助于在项目中尽早发现潜在问题，以便有机会在施工开始之前进行更改。 有效的架构模式可提高代码的可读性，因为它们需要考虑直到以后才变得可见的问题。 什么是建筑设计模式？ 设计模式是针对软件设计中常见问题的可重用解决方案。 它们是旨在帮助我们编写易于理解，易于测试和易于重用的代码的模板。 设计模式有助于创建松耦合的代码，以便以后可以在代码中轻松更改或替换其组件。 使用设计模式构建应用程序确实可以为您带来回报。 开发人员非常了解我们的应用程序会发生变化：您可能想添加新功能，可能需要修复一些错误，您的雇主可能会要求您在视图控制器上快速更改配色方案，或者您可能需要更新您的代码以与新版本的iOS软件或新设备保持兼容。 架构设计模式是使您的应用程序能够应对这些更改的准则。 现在我们已经回答了“ 为什么？ 让我们来看看“ 如何？ ” iOS设计模式： iOS开发最常见的设计模式是： MVC ， MPV ， MVVN和Viper 。 我将仅介绍MVC和MVVN，因为这些是我目前最感兴趣的设计模式。 在此博客中，我将重点关注MVC，接下来是关于MVVN的后续博客。 什么是MVC？ 模型视图控制器（MVC）由Trygve Reenskaug于1979年发明。它是iOS开发中最常见的面向对象设计模式。 MVC可以非常清楚地分离应用程序的数据-逻辑，视图和控制器。 MVC根据对象的一般角色对它们进行分类，并鼓励根据每个角色对代码进行清晰的分离。 每个对象都属于以下组之一： 该模型负责数据和逻辑：诸如持久性，模型对象，解析器和网络代码之类的内容都存放在这里。 视图负责负责模型的可视化表示的对象以及用户可以与之交互的控件； 想任何以“ UI”前缀开头的东西。 Controller充当应用程序的视图对象及其模型对象之间的中介。 控制器编排查看事件和模型更改。 现在，我们了解了MVC如何管理这三个阵营之间的通信，我们的工作是根据每个对象所扮演的角色来明确区分代码。 遵守MVC设计模式需要不断关注对象的位置，以避免潜在的陷阱。 以下是一些需要牢记的准则： 控制器可以与之对话并了解有关该模型的所有信息。 控制器的工作是从模型中获取所需信息以显示给用户。 控制器还可以通过我们在控制器中创建的插座直接与视图对话。 视图只是控制器的奴才 -保持视图简单！ 模特和模特 永远都不要说话。 MVC的缺点： 设计模式没有万灵药。 在MVC中，视图和控制器紧密耦合。 iOS视图控制器类通常将同时包含UI逻辑和数据逻辑，这将使一个逻辑的修改影响另一个逻辑-创建MVC的一种“ M / […]
细胞协议铸造
多单元转换可能是使用大型视图控制器的最大原因。 我已经在互联网上进行了广泛的搜索，发现的并不是一个庞大的视图控制器。 我敢肯定我们都看过这样的东西👇👇👇👇👇 不，我不会谈论MVVM。 我们可以做得更好！ 第一个解决方案将是Swift 4.2，然后是Swift 4.1 30号线 UserTableViewControler符合CellDelegate 可能不是分配委托的最佳方法。 但这是避免多细胞铸造的关键。 您还可以避免对多个单元格进行检查，从而使tapped（）成为可选选项，但是我很累，因此我将让您弄清楚这一点。 1号线 参数类型T提供了更大的灵活性，并避免了针对不同数据类型的多种协议。 由于CaseIterable在swift 4.1上不可用，因此枚举的RawValue类型为Int，标识符变量返回单元格标识符。 而已！ 其他一切都保持不变。 在GitHub上下载完整的解决方案。 Swift 4.2 https://github.com/ErickApps/ProtocolCellsSwift4.2 Swift 4.1 https://github.com/ErickApps/ProtocolCellSwift4.1 确保跟随这些家伙 保罗·哈德森 推特：@seanallen_dev 推特：@buildthatapp 雷·温德利希 结论 不是MVVM解决方案🤪 减少键入和调试。 不再施力👇👇👇👇👇👇 批评总是受到欢迎。 在Twitter上让我知道：@ pitjits u
