iOS 模态出视图控制器模型视图控制器模式

转载

mob64ca14193248 2023-12-20 09:31:20

文章标签 iOS 模态出视图控制器 MVC 应用程序数据 文章分类 iOS 移动开发

模型视图控制器（MVC）一个相当实用且十分流行的设计模式。作为一位称职码农，你不可能没听说过吧。不幸的是它难以让人理解。在本文中，我将给出我认为是MVC的最简单的解释，以及为什么你应该使用它。

什么是模型 - 视图 - 控制器（MVC）？

在一个典型应用中，你会发现这三个基本组成部分：

数据（模型）
查看和修改数据的接口（视图）
可以对数据施加的操作（控制器）

MVC模式，简言之，就是：

模型代表数据，除此之外别无它用。模型不依赖于控制器或视图。
视图显示模型数据，发送用户动作（例如按钮点击）到控制器。视图可以：

独立于模型和控制器的; 或者

作为控制器，因此依赖于模型。

控制器提供模型数据至视图，解释用户的行为，如按钮的点击。控制器依赖于视图和模型。在一些情况下，控制器和视图可以合二为一。

规则1是MVC的黄金法则，我再重复一遍：

模型代表数据，除此之外别无它用。模型不依赖于控制器或视图。

以一个地址簿应用程序为例。模型是一些Person对象，视图是一个GUI窗口，显示联系人列表，并且控制器处理用户行为诸如“删除联系人”，“添加联系人”，“发邮件至联系人”等。下面的例子没有使用MVC，因为模型依赖于视图。

//Example 1:
void Person::setPicture(Picture pict){
    m_picture = pict; //set the member variable
    m_listView->reloadData(); //update the view
}

下面的示例使用了MVC：

//Example 2:
void Person::setPicture(Picture pict){
    m_picture = pict; //set the member variable
}

void PersonListController::changePictureAtIndex(Picture newPict, int personIndex){
    m_personList[personIndex].setPicture(newPict); //modify the model
    m_listView->reloadData(); //update the view
}

在上面的例子中， Person类并不知道视图的存在。 PersonListController负责模型修改和视图更新。视图窗口告诉控制器用户的行为（就上述情况而言，它将提醒控制器用户修改了一个联系人的照片）。

MVC的优势在哪里？

不必要的复杂性是软件开发的梦魇。它导致软件漏洞百出，维护费用昂贵。而到处引入依赖很容易就会造成代码过于复杂。相反地，如果我们移除不必要的依赖可以改善代码质量，维护上更容易，因为代码可重复使用而无需修改。你可以安心地复用旧的、稳定的代码不用顾虑招致新的bug。

MVC设计模式的主要优点是：

MVC使得模型类不加修改即可重复使用。

控制器存在的目的是消除模型与视图依赖关系。从模型中移除视图依赖后，模型代码变得整洁起来。

为什么模型代码能这么小清新？让我们继续以地址簿应用为例。项目经理找到码农们，对他们说 ”我很欣赏联系人列表窗口，但我们需要另一个窗口显示所有联系人的照片，这些照片应该是处于一个表格布局中，每排五张照片。”

如果应用程序采用了MVC，这个任务相当简单。目前主要有三个类： Person ，PersonListController和PersonListView。还需要创建两个类： PersonPhotoGridView和PersonPhotoGridController 。在Person类保持不变的情况下，很容易插入两种不同的视图。怎么样啊！

如果应用程序具有例1中类似的结构，任务立马变得棘手了。此时有两个类Person 和PersonListView 。Person类不能插入另一种视图，因为它包含了涉及PersonListView类的具体代码。开发人员必须修改Person类以适应新的PersonPhotoGridView

//Example 3:
void Person::setPicture(Picture pict){
    m_picture = pict; //set the member variable
    if(m_listView){ //check if it's in a list view
        m_listView->reloadData(); //update the list view
    }
    if(m_gridView){ //check if it's in a grid view
        m_gridView->reloadData(); //update the grid view
    }
}

如你所观察到的一样，模型代码开始变得苦涩。如果项目经理接着发话：“我们正在移植的应用程序到一个使用不同的GUI库的平台”，简洁性此时尤为突出。采用MVC的Person类可以通过不同的GUI工具包显示无需任何修改。单单创建一个控制器，并用新的库中的视图，就像你用旧的库一样。如果没有MVC，支持多种GUI工具包将是一场噩梦。最终代码可能会这样的：

//Example 4:
void Person::setPicture(Picture pict){
    m_picture = pict;
#ifdef ORIGINAL_GUI_TOOLKIT
    if(m_listView){ //check if it's in a list view
        m_listView->reloadData(); //update the list view
    }
    if(m_gridView){ //check if it's in a grid view
        m_gridView->reloadData(); //update the grid view
    }
#endif
#ifdef NEW_GUI_TOOLKIT
    if(m_listView){ //check if it's in a list view
        m_listView->redisplayData(); //update the list view
    }
    if(m_gridView){ //check if it's in a grid view
        m_gridView->redisplayData(); //update the grid view
    }
#endif
}

setPicture方法基本上会乱上一团。

为什么不把控制器代码置入视图？

一直解决例4中的尴尬代码的方案是将控制器代码从模型移动到视图，像这样：

//Example 5:
PersonListView::newPictureClicked(Picture clickedPicture){
    m_selectedPerson.setPicture(clickedPicture);
    this->reloadData();
}

上述例子也可使模型易于复用，这是MVC的主要优势。当视图将只显示一种类型的模型对象，合并视图和控制器是比较合适的。例如，一个SinglePersonView将只显示一个Person的对象，所以SinglePersonView可兼作控制器。

然而，如果控制器与视图分离，MVC有第二个优点：

MVC可以使视图可重复使用的而无需修改。

MVC模型不仅使得模型简洁，视图同样如此。理想情况下，列表视图应该能够显示的任何列表，不只是Person的对象。例5中的代码不能是一个通用的列表视图，因为它与模型耦合在一起（Person类）。要想视图（如列表视图，或表格视图）和模型代码同时可重复使用，MVC是唯一的选择。控制器移除模型和视图间的依赖关系，这使得它们在其他地方可以被复用。