Tag: Mvc

Swift-MVC

MVVM ， MVP和VIPER 几周以来，我一直在尝试了解有关iOS建筑模式的更多信息。 作为基本MVC的一部分，您可以找到有关MVVM，MVP和VIPER的一些不错的文章。 iOS架构模式 MVVM简介 使用VIPER架构iOS应用 我不确定他们。 而且我还是很困惑。 最后， Bohdan Orlov在他的文章中说：“ 没有灵丹妙药， 因此选择架构模式只是在您的特定情况下权衡取舍的问题 ”。 我也有类似的想法。 当您可以使用更好的MVC时，为什么将所有架构决策押注在某种时髦的流行模式上？ MVC 我完全同意MVC被破坏的事实，因为View和Controller集成在同一文件中。 这是事实，使MVC成为谎言。 我还认为采用这种替代模式是因为Objective-C的功能不如Swift强大。 老实说，由于Swift，我们可以以其他方式使用MVC。 现在要容易得多。 扩展功能更加强大且显而易见。 结构和枚举现在是真实的模型结构。 易于理解和使用。 因此，如果使用MVVM ， MVP和VIPER也很痛苦，为什么我们不简单地使用MVC ？ 搜索图案 我想学习如何使用HealthKit Framework ，所以几天前开始了一个项目。 我正在使用该项目来发展和研究有关如何在Swift中使用MVC的想法。 距离完成还很遥远，但是我要坚持下去。 每天都在发展和更改代码。 Swift-MVC 线索之一是使用扩展来尽可能多地移出ViewController。 视图：UIViewControllerIt是View 。 所有View Life Circle都在那里，因此仅将View代码放入ViewController中。 控制器：扩展 将所有Delagate和Data Source代码添加到新的扩展文件中。 我们通常将View Controller内部拥有的所有逻辑扩展到一个新的扩展逻辑文件。 模型 结构和枚举。 将所有数据模式转换为新文件 通过这种结构，ViewController的长度为100行。 结论 […]

MVC-RS

RS字母在汽车工业中经常用来指代给定汽车的最强大版本。 对于MVC-RS，适用相同的想法：它是MVC，但是由于另外两个额外的层（路由器和存储），功能更加强大。 香草MVC MVC的第一个版本是在70年代与SmallTalk一起推出的，旨在满足GUI应用程序不断增长的需求。 苹果公司推荐的用于构建应用程序的MVC新版本略有不同。 在此版本中，视图层和模型层不再相互了解。 完全分离这2个层的主要优点是使它们可重复使用。 但是，具有可重复使用的层意味着什么？ 可重用性 Swift可以在所有Apple平台，iOS，macOS，watchOS和tvOS上重用，但也可以在Linux上以及某些天在Windows和android上重用。 重用View层与重用一些通用代码不同，因为View与它们所运行的平台紧密耦合。 这是有道理的，您没有呈现相同类型的UI，也不允许在手表，手机，平板电脑，计算机或电视上进行相同类型的用户交互。 如果您在macOS上编写了View层，则使用了AppKit，因此，只有在AppKit可用的情况下，该层才可以重用，这意味着只能在macOS上使用。 Model层没有View这样的约束，因此您应该能够在所有支持该语言的平台上重用Models。 您在iOS开发中经常遇到的第一个常见错误是在模型中使用UIKit。 Apple并没有为您提供帮助，因为他们在文档和某些WWDC会话中都犯了同样的错误。 这样做的问题是您不再可以在其他平台上重用Model。 让我们看一下这个例子： 在上面的示例中，您有3个不同的数据库提供程序。 如果您使用的是db A，则可以在任何地方重用Model。 但是，您可能还在macOS项目上使用了db C，并且该数据库在任何其他平台上均不可用。 在这种情况下，您的模型将无法在其他平台上重复使用。 这里的问题是，当您考虑MVC时，总是只考虑这三个层：模型，视图和控制器。 但实际上，有一个隐式的第四层：持久性（通常是本地文件，本地数据库或远程调用）。 如果您的模型知道您的持久性，则只有在您的持久性可用的情况下它才可以重用。 为避免这种情况，让我向您介绍MVC-RS的S层，它代表存储。 存储 存储层将只在您的持久性和模型之间进行，它将有2个任务： 与持久性交谈 将原始数据从“持久性”转换为模型的实体 与持久性交谈 此任务比看起来要复杂，因为对持久层的调用是异步的，因此它们可能会成功，但也可能会失败。 您的存储层将必须考虑所有这些参数。 转换数据 当您读取应用程序将呈现给用户的数据时，您的存储层会将从持久性获得的原始数据转换为模型的实体。 但是它也应该能够以其他方式做到这一点：当您的应用程序需要保留某些元素时，您的存储层应该知道如何将模型的实体转换为原始数据，并将其发送给Persistence。 重要的是要记住，这两个任务都可能失败。 例 在本文的示例中，您将看到之前的简单Car Model和非常方便且常见的Result枚举模式，而不是繁重的do-try-catch语法来管理错误。 这是您可能在存储层中找到的示例。 读取方法不会立即返回，因为对持久性的调用是异步的。 它们将闭包作为参数，当存储工作完成时将调用它。 如果在与Persistence交谈或将原始数据转换为Model实体时发生故障，则将调用onComplete闭包并显示错误，否则将使用适当的Model实体进行调用。 您可能会发现不同的读取方法，例如一种使用id来获取模型的单个实体的读取方法，或者另一种使用一些参数的读取方法，以防您不想加载模型的每个实例。 编写方法，创建，更新和删除完成了此CRUD示例。 它们具有相同的签名：它们采用Model的实体和onComplete闭包。 如果在将Model实体转换为原始数据或将该原始数据发送到Persistence时失败，则将调用onComplete闭包并显示错误。 否则，将以nil调用。 优点 将存储定义为协议非常方便，因为它允许您针对不同类型的持久性编写不同的实现。 您可能会发现一个用于sqlite数据库的数据库，另一个用于Couchbase数据库的数据库，一个用于某些Rest API调用的数据库……如果您要模拟持久性，还可以编写一个实现用于测试目的。 […]

模型-视图-视图模型的建筑模式– Anil Sutariya –中

Model-View-ViewModel体系结构模式 iOS / Swift应用程序使用的Model-View-ViewModel（MVVM）体系结构模式。 MVVM是MVC的扩展，我们在其中正式将视图和控制器耦合在一起，但是将所有表示逻辑从控制器中移出到称为视图模型的新对象中。 在iOS / Swift上下文中，视图的角色由view + view控制器组合完成（参见图）。 在iOS上使用 Figure Model-View View-Model模式 这三个组成部分的作用总结如下： 模型：负责存储数据，与视图模型保持双向通信。 视图/视图控制器：表示模式的视图部分，并处理用户交互事件。 与视图模型保持双向通信。 视图模型：处理表示逻辑，与模型和视图/视图控制器保持双向通信。 处理与可能提供特定功能（如复杂的业务逻辑和网络请求）的其他控制器的通信。

在下一个项目之前，请学习MVVM

我不是iOS开发专家。 经过一个月的学习，我最近开始在Swift中为多个行业开发应用程序。 我确实喜欢每个初学者，并打开了Apple文档，并遵循了他们的指南。 苹果公司推荐的模式是MVC模式。 我按照大家都知道并珍惜的Model View Controller的经典原理开始构建自己的第一个应用程序。 从表面上看，iOS开发中的MVC模型与我们多年来使用的模型没有什么不同。 对我来说不幸的是，我一直对软件体系结构，简洁的代码和漂亮的软件感兴趣，因此将iOS和MVC结合使用非常麻烦。 几周后，随着视觉和幕后应用程序变得越来越复杂，问题就显而易见了。 在为iOS开发时，您的视图（也称为Storyboard）是一个简单的XML文件，其中包含所有不同的组件以及它们的坐标和约束。 这样做的结果是，与实例的实际功能相比，负责实例化和管理这些视图的ViewController文件变得混乱而庞大。 您开始在同一类中查看混合在一起的不同关注点：路由，模型处理，动画，视图填充…都在一起💀。 这种使用起来令人困惑和痛苦的方法，通常被称为Massive View Controller综合症。 于是去寻找其他选项，然后在此处输入MVVM 。 MVVM模式或模型视图ViewModel围绕应将模型处理和视图处理分开的想法而展开。 这样可以实现更好的可测试性，可读性并易于开发。 为此，我们将ViewController分为二。 View （仍然继承自Apple ViewController类）将填充视图并管理动画。 屏幕上显示的所有内容均受其控制。 ViewModel负责与API，数据库和其他信息源进行交互，并提取与其相应视图有关的信息。 实例化视图时， View将自身绑定到其ViewModel并将根据ViewModel提供的数据进行更新。 有多种方法可以实现这一点，但是Swift提供的我的首选方法是通过闭包。 为了说明这一点，让我们想象一个打印当前日期的愚蠢视图。 我们可以从设计ViewModel开始： 简单的ViewModel示例 这里， ViewModel公开了一个变量和一种方法。 fetchDate()方法将获取当前日期并为其分配一个私有变量。 每次设置此变量时，都会调用一个可选的公共方法updateDate 。 此方法是一个公共变量，可以通过View设置这样的方法： 简单检视 实例化ViewModel ， View会将其闭包简单地附加到其ViewModel的公开变量，然后触发获取。 如果需要，setupView方法将使用初始内容填充视图。 当获取成功完成并且在fetchDateFromApi函数上updateDateClosure了回调时，将updateDateClosure并更新标签。 所有这些异步且易于维护。 唯一令我烦恼的是， View仍然必须通过prepareForSegue和其他方法来处理路由。 在实现表示和模型处理之间的清晰分离之后，我们不能简单地乐于在这种情况下进行路由。 为了解决这个问题，我创建了一个简单的路由器协议（与旧接口的Swift等效）： 基本但清晰的路由器实现 viewController的init方法是一种便捷的init方法，无需查找相应的Storyboard 。 枚举和协议只是为了清楚起见。 但这使我们可以在文件中简单引用此路由器： 将路由器添加到先前的类中 […]

MVC。 对于那些喜欢委托的人。

模型，视图，控制器。 这个想法比任何Web应用程序都要古老得多。 最初在1979年被描述为“ MVC不是设计模式，它是一种架构模式，它描述了一种构造我们的应用程序以及该结构中每个部分的职责和交互的方式”。 不难看出如何将MVC应用于不仅仅是架构。 该模型处理所有幕后工作。 它包含所有可调整应用程序当前状态的功能。 它可能包含位置数据，游戏的当前棋盘状态，以及通常使应用程序运行的齿轮。 模型 控制器是处理用户输入并根据接收到的输入调用模型以运行特定功能的部件。 控制器应该是应用程序中相当轻便的一部分，因为它的唯一工作就是委派给模型和视图。 控制者 该视图是呈现给用户的应用程序当前模型的直观表示。 由于更改的速度和广度以及所述更改的呈现，该视图可能比其他两个视图更喧闹。 这被认为是不正确的做法，但是某些应用实际上会在任何状态更改时重新渲染整个视图。 视图 如果您仍然想知道为什么应该使用MVC，我希望您回顾一下此博客。 现在想象一下，三个定义的部分不再分开了，而不是将代码示例分开了，它们只是在底部的一行中。 那不会更难阅读吗？ 仍然很难弄清楚哪个部分是哪个代码？ 虽然MVC可能不是永远的项目，也不是每个人都可以，但给它一个机会。 您可能会发现它多么有用，令人惊讶。

UIKIT APP的基础知识（MVC和MVVM）

这适用于iOS App开发的初学者或各个阶段的所有开发人员，他们真的想回顾一下基础知识。 如今，所有iOS开发人员都在努力将其应用程序设计转变为MVVM设计模式，但是所有开发人员都知道为什么这样做吗？ 还是您中的一员，谁正在更改模式，因为您的高级开发人员想要更改。 我会解释“ 为什么 ”，不用担心don 首先，我想让您知道UIKIT应用程序基于MVC（模型-视图-控制器）设计模式。 模型 –就像是您的应用程序的宝贵资源，就像您想要在应用程序上显示的数据，其应用程序的数据以及业务逻辑一样，可以帮助将数据修改为应用程序中更具表现力的方式。 视图 –主要处理用户界面，它是数据的可视界面。 控制器 –就像模型和视图之间的桥梁一样，它在适当的时候从模型和视图之间移动数据，反之亦然。 请查看下面由Apple提供的有关MVC设计模式如何工作的图像。 在了解了MVC的知识之后，让我们开始MVVM。 我将以最简单的方式来描述MVVM，MVVM只是MODEL-VIEW-VIEWMODEL。 在这种情况下， Viewmodel充当View和Model之间的桥梁。 在大多数情况下，业务逻辑也从Model插入，并在ViewModel中完成。 其次，在这种情况下， View仅用于发布内容，它仅显示分配给它及其子视图的内容，应显示的内容以及应如何显示的内容再次由ViewModel处理。 看起来ViewModel是此设计模式中的主角。 那么，为什么许多iOS开发人员更喜欢MVVM而不是UIKIT的MVC？ 当涉及到Xcode Project时，当您尝试在UIKIT APP中创建ViewController时，将以如下所示的形式创建它： 您可以看到Controller是用自己的View创建的，它们就像密不可分，因此，如果您要对Controller进行单元测试，它实际上涉及View，那么模拟ViewController非常困难，并且您需要做很多事情不知道ViewController会发生这种情况，而我们实际上没有任何控制权。 最后，您实际上没有机会独立测试实际的业务逻辑。 在MVVM设计模式中，您实际上可以独立地测试业务逻辑，可以将业务逻辑与模型分离，可以分离数据的转换方式，以便在View中显示，并且模拟ViewModel真的很容易。 如何将给定的UIKIT的MVC设计转换为MVVM，请查看以下图像： 至 因此，为了将MVC更改为MVVM，您需要一个额外的文件，例如：ViewModel.swift并将所有逻辑拉入其中，只是将整个ViewController视为MVVM。 因此，在这里，ViewController的部分是发布或显示数据和视图。 如果ViewController（在MVVM中为视图）要发布某些内容，则它应该来自ViewModel，后者再处理来自Model的数据以将其提供给ViewController。 如果用户想要更新其数据，则用户将更新屏幕上的数据，并将该信息发送到ViewModel，后者将更新模型。 那是最终读者，希望大家喜欢这篇文章。 如果您有任何疑问或想念任何内容，请在💁下方评论。 朱丽叶编码器签字……

iOS中的MVC方法

MVC是一种将代码分为三个不同部分的体系结构模式。 模型视图控制器。 这是一种流行的体系结构，因为它将用户界面代码与逻辑代码分开。 因此，可以更轻松地在错误发生时进行更新，扩展和查找错误。 三个不同部分的简要概述。 模型 -模型是处理大多数逻辑和数据过程的地方。 视图 -您的UI元素将位于此类内。 由于它不包含任何逻辑，因此也称为伪类。 控制器 -这是模型和视图之间进行交互的地方。 控制器管理这些交集。 在iOS开发中，将所有代码编写在ViewController可能是诱人的; 实际上，如果您是一个自学成才的开发人员，您可能会实践过。 在本文中，我将演示如何在应用程序的简单注册功能上执行此操作。 我喜欢以编程方式执行此操作。 因此，如果您关注以下内容，请删除Storyboard文件，并确保在项目设置中将“ Main Interface选择保留为空白，并在AppDelegate.swift初始化rootViewController 设定 我将创建三个文件： Register RegisterView和MainController 。 我们的Register类将充当我们的模型，其中将包含我们的所有逻辑。 RegisterView将充当我们的View，并将包含我们的所有用户界面元素，并且MainController将托管RegisterView 。 注册—模型 在本课程中，我们将使用用户名和密码。 我们想对密码的格式化方式添加一些限制。 首先，我希望密码长度至少为6个字符，并且在继续操作之前，密码和确认密码必须相同。 我们没有使用数据库来保存任何信息。 首先，让我们设置初始化程序，该初始化程序将使用用户名，密码和确认密码。 在那之后，我想要三个功能。 validatePasswordLength() validatePasswordAndConfirmPassword() completeRegistration() validatePasswordLength()少于5个字符时将引发错误。 如果validatePasswordAndConfirmPassword()不相等，也会抛出错误。 completeRegistration（）函数将在try块中同时调用validatePasswordLength()和validatePasswordAndConfirmPassword()函数。 因为我们正在使用try块进行错误处理，所以我们需要一个enum不同的错误。 枚举验证：错误{ 案例密码太短 案例密码 } 完成后 您的代码应如下所示： RegisterView —查看 如前所述，此类将包含我们的UI元素。 对于此注册页面，我们想向用户询问用户名和密码。 我们还希望另一个密码字段来确认密码。 因此，我们总共需要三个UITextField。 我们还需要一个按钮来执行注册操作。 […]

MVC-组织代码的模式

MVC代表模型，视图和控制器。 它是一种体系结构，您可以使用该体系结构来组织代码，以便任何人以及您每次引用代码时都可以轻松理解它，因为那样的好代码可以被包括您在内的任何人轻松阅读。 有两种方法可以执行任何工作：要么在开始时就没有任何计划/架构，要么只是想到一个想法，然后就着手进行工作（尽管这是一个糟糕的方法），或者先计划好工作，例如您将如何实现该想法或创建一种架构类型，以便您可以轻松地分析自己在做什么以及您将如何进一步发展（这是一种更好的方法）。 也许您将能够使用这两种方法来完成您的工作，但是使用第二种方法，完成任务的可能性将会增加，并且最终结果将是效率更高的理想结果。 例如，如果我们谈论建造一座建筑物，那么我们都知道，首先，建筑会绘制一张正确的地图，因此建造者会建造该建筑物。 我们将通过日常生活示例来了解MVC的概念，以便您可以轻松地将其关联起来，并且可以更轻松地理解该概念。 有什么看法？ 顾名思义，这是最终用户可见的应用程序部分（在阅读本文时，您是最终用户），该用户可以与应用程序的所有功能进行交互，并且可以能够输入一些数据以及以往的数据。 在应用程序的视图部分中定义了负责用户界面的所有代码。 让我们举个例子，假设您非常饿（您当时在吗？哈哈，开玩笑），然后您去一家餐馆浏览菜单并为您点菜，点菜在技术上是在您的数据中输入数据应用程序，您想要根据您的订单结果。 一段时间后，食物就在您面前，这与根据您的需要显示数据相同。 什么型号？ 显然，如果您正在开发将处理大量数据的应用程序，则数据处理是主要问题之一。 处理和处理如此大量的数据有时会令人头疼，但是这要归功于MVC模式的模型部分。 在这一部分中，我们定义数据的类型，即，如果我们要向用户询问用户名和密码，那么期望用户输入哪种数据类型（或者可以说，应用程序中处理数据的部分）相关功能定义模型）。 例如，如果我们的应用程序要求密码，并且密码必须至少包含7个字符，但是如果用户输入6个字符作为密码，则该密码将不被接受，因为这与我们的模型设计背道而驰。 继续我们的餐厅示例，在接受您的订单后，订单将发送给厨师以准备食物。 现在准备食物，厨师将打开冰箱，放所有配料。 在这里，您可以将冰箱与一个数据库相关联，该数据库将包含烹饪食物的所有成分，而此处cook是一个模型，该模型将根据他/她准备食物的需求从数据库/冰箱中获取数据。 什么是控制器？ 您所有的应用程序逻辑，即如何处理数据或如何访问用户请求或向用户显示什么，所有这些都在应用程序的控制器部分中定义。 它就像视图和模型之间的桥梁，或者顾名思义，它充当应用程序的视图和模型之间的控制器。 在我们的餐厅示例中，服务员充当控制器。 当食物准备好时，服务员将把食物从厨房拿到顾客那里，而厨师可能会拿着其他一些餐桌上的订单，因此服务员/控制器的工作是将正确的订单送达正确的桌子。 随着对MVC模式读取的越来越多的使用，代码的共享和可重用性也得到了提高。 想象一个应用程序，您在其中编写了所有代码（意味着没有代码分区），也就是说，所有代码都写在同一位置，并且相信我会造成很大的混乱。 同样，如果您在应用程序中使用MVC模式，那么可以在同一应用程序上一起工作的人很多，一个人处理视图部分，一个处理逻辑部分，依此类推。 MVC模式不仅限于特定的语言，该体系结构可用于任何技术。

模型视图控制器（MVC）

Model-View-Controller（MVC）设计是一个与应用程序的全局体系结构有关的高层，并根据对象在应用程序中扮演的一般角色对对象进行分类。面向对象的程序通过适应MVC可以从多种方面受益他们设计的设计模式。 这些程序中的许多对象倾向于更可重用，并且它们的接口倾向于更好地定义。 它主要包括三层： 1）模型层 2）查看图层 3）控制器层 1）模型层： 模型层包含以下组件： 网络代码 ：此代码对于整个应用程序的网络通信非常有用 持久性代码：此代码用于实现核心数据，或仅通过将NSData blob直接保存到磁盘即可。 解析代码：解析网络响应之类的任何对象也应包括在模型层中。 模型对象封装了数据和基本行为，它们保存了应用程序的数据并定义了处理数据的逻辑。设计良好的MVC应用程序将其所有重要数据封装在模型对象中，任何数据都是应用程序持久状态的一部分一旦将数据加载到应用程序中，它应该驻留在模型对象中。 理想情况下，模型对象与用于呈现和编辑它的用户界面没有显式连接。 模型对象不应与界面和表示问题有关。 2）视图层： 当用户与您的应用进行交互时，他们正在与视图层进行交互。 视图不应该包含任何业务逻辑，因此被认为是应用程序的“哑巴”部分。 用代码术语，您通常会看到： UIView子类：这些类从基本的UIView到复杂的自定义UI控件。 UIViewController： UIViewController与自身的根UIView及其不同的周期（LoadView，ViewDidLoad）紧密耦合。 动画和UIViewController过渡。 UIKIT / APPKIT，Core Animation和Core Graphics的一部分的类 检查视图图层时，请使用以下内容作为检查清单： 它是否与模型层交互？ 它是否包含任何业务逻辑？ 它会尝试执行与UI不相关的任何操作吗？ 如果我们很好地编写了这些类，则几乎可以随时重用它们。 视图对象向用户提供信息。视图对象知道如何显示并可能允许用户编辑应用程序模型中的数据。视图不应负责存储其显示的数据。视图对象可以位于负责仅显示模型对象的一部分，整个模型对象，甚至许多不同的模型对象。 视图有很多不同的种类。 视图对象倾向于可重用和可配置，并且它们在应用程序之间提供一致性。 在Cocoa中，AppKit框架定义了大量的视图对象，并在Interface Builder库中提供了许多视图对象。 通过重用AppKit的视图对象（例如NSButton对象），可以确保应用程序中的按钮的行为与其他任何Cocoa应用程序中的按钮一样，从而确保了应用程序之间外观和行为的高度一致性。 视图应确保其正确显示模型。 因此，通常需要了解模型的更改。 由于模型对象不应绑定到特定的视图对象，因此它们需要一种通用的方式来指示它们已更改。 3）控制器层： 控制器层是应用程序中最少可重用的部分，因为它涉及特定于域的规则。 控制器对象将模型绑定到视图。控制器对象充当应用程序的视图对象及其模型对象之间的中介。 控制器通常负责确保视图可以访问他们需要显示的模型对象，并充当视图了解模型更改的渠道。 控制器对象还可以为应用程序执行设置和协调任务，并管理其他对象的生命周期。 在典型的Cocoa MVC设计中，当用户通过视图对象输入值或指示选择时，该值或选择将传达给控制器对象。 控制器对象可能以某种特定于应用程序的方式解释用户输入，然后要么告诉模型对象如何处理此输入。 基于相同的用户输入，某些控制器对象还可能告诉视图对象更改其外观或行为的某个方面，例如告诉按钮禁用自身。 相反，当模型对象发生更改时（例如，访问新的数据源），模型对象通常会将更改传达给控制器对象，然后控制器对象请求一个或多个视图对象进行相应的更新。 MVC作为复合设计模式： Model-View-Controller是一种设计模式，由多个其他基本设计模式组成。这些基本模式共同定义了MVC应用程序的功能隔离和通信路径。与可可分配的基本模式不同的一组基本模式。 […]

MVP，MVC，MVVM和VIPER。 什么对iOS开发更好？

Same like every house has a solid basement, every software project, has an software architecture it is built on, and each project has its own app structure. The types of architectural patterns may vary, but there are 4 most commonly-used ones – the ones whole IT world continuously criticizes but keeps using at the same […]