从架构开始重新认识Day2

MVC介绍

希望能将复杂的东西简单化

如果给我一句话我会说下面这句

Model、View、Controller 的区分，是希望能把应用程序的内部运作归纳成不同的部门，是一种物件导向的应用

那麽再来详细说明其中Model、View、Controller之间的关系

Model 负责和资料库沟通，要和资料作出CRUD的话，需要先将资料从资料库存取到应用程序的某程序物件中

注：CRUD是指(Create Read Update Delete)

主要负责商业逻辑

View 负责管理画面的呈现

Controller 负责掌控互动逻辑，由Controller负责通知其他层，类似MVC架构的传信人

像是负责带着Data在view跟model之间

这张图取自Apple的官方文件，揭示一些这些分工之间是如何彼此沟通

从工作最多的Controller开始说起（Model跟View应该算是易懂)

刚刚说了Controller是个传信人

• Ｑ：这个传信人首先需要传信那麽信是哪来的？
  • Ａ：Model层（负责资料的部分) // Model to Controller
• Ｑ：这些信要给谁，是谁要使用？
  • Ａ：大机率都是给View层使用(负责呈现的部分) // Controller to View
• Ｑ：当其他人要看其他信(View)的时候？
  • Ａ：通知传信人(Controller层)来说要哪些东西 // View to Controller
• Q：传信人该去找谁？
  • Ａ：该去找会有这些信资料的地方(Model层) // Controller to Model

上面我们完成了这四条线的彼此交织

下面分享一张Chiwen Lai大神的MVC图（网址会附在最下面）

这张图很清楚地把会在Swift开发上会用到的几个通知方式都列了出来

1. Controller去找Model挖资料
2. Controller透过@IBOutlet去通知View呈现
3. View 通知 Controller有3个方法
   1. Target-Action
   2. Delegate(View指派Controller作为代表负责做事)
   3. Data Source(View 询问 Controller 资料呈现）
4. Ｍodel层透过下面两个方法来联络Controller
   1. Notification
   2. KVO

在官方文档下写着

ViewController主要的职责有

• 更新view中的内容，
• 回应使用者互动 在view下
• view的Layout
• 通知其他的物件（包括其他的ViewController)

好处：

方便使用重复已经完成的程序码

方便维护各自架构下的程序码

方便多人分工

缺点：

需要进行多一点事前规划

需要维护的档案也较多

结语：

因为iOS开发是透过MVC架构，故了解MVC架构下能够更能了解为何要用ViewController、View 等

参考链结

[APP开发-使用Swift]观念介绍: MVC