引入框架
什么是框架？
很多课程都会提到所谓的框架。进入实习前，总觉得那是很大的，可能需要有某些组件或者其他不一样的东西来作为基础进行搭建的环境。
实际接触过后，其实所谓框架，主要是作为一种开发规范存在的，它的实现并不一定要依赖于什么。
为什么存在框架？
在实际的大型项目进行开发时，通常有几十号人共同对项目动手动脚。尤其是到了修复bug的日子里，一天可能提交上百条修改记录，日常也会有几十条，这都是很正常的。而很明显，大家的习惯不同，语言经历不同，对于代码的思考方式也不同，自然会写成千奇百怪的样子。这样的系统往往是弱读的。对于在项目中的人来讲，甚至有的时候会无法辨认自己的代码，因为别人通过奇怪的方式引入或者剔除了什么东西。更不用说没有那么多人会写注释，对吧。
这个时候一个框架的重要性就会体现出来。它会把代码按照一定的功能进行划分，这样一来，某些复杂结构就会按照固定的方式组织，而终端无论如何也仅仅是实现某些特定功能，整个项目的可读性会有质的提升。
接下来是例子
我们都知道unity存在委托，事件，action等组成的观察者模式。然而每个人的习惯不同，有人会在特定的地方组织事件，而有的人会想到一出是一出。然后不同的功能阶段会对不同的事件或代码进行复用，项目会逐渐打成死结，最后一定会出现所谓的屎山代码。
好，我们现在进行规定，每一个大的功能会有多个组成部分，而其中如果需要用到事件，则为其新建一个固定事件脚本。最后虽然会出现数量庞大的脚本量，但可读性上升了很多。
如果我们为每个大功能下进行不同功能分类，将事件与部分有相同特点的代码整合起来，就会将脚本的数量减少，同时我们规定一定结构，而每个脚本按照固定功能与结构划分，代码会有极强可读性的同时，将脚本数量降低。
简单谈谈MVP框架
框架结构
所谓MVP框架，是Model-View-Presenter。
即模型-视图-逻辑层（并不标准的叫法）。
1.Model层
这一层主要负责数据，比如外部二进制文件，json文件，文本文件等。其中根据项目的具体需求，可以划分为Defination以固定格式与数据连接，Model层作为数据模型，然后可以为其创建一个数据类用于初始化模型。
2.View层
这一层自然是负责视图部分，MVP框架主要是UI框架，所以这部分主要是UI，包括图片，文本，以及其他页面的部分。根据需求，往往会划分为Page外部调用的初始化UI，Window作为单个页面存在，Param多个连续窗口。
3.Presenter层
这一层说简单也简单，说复杂也复杂。简单在于一般只存在Presenter，而复杂在于，这一层将处理所有的逻辑。比如来讲，View层的Button事件注册需要连续调用，直到Presenter层进行事件逻辑实现及注册。
4.其他可能用到的
我知道的是仓库Regestroy，当数据量较大，或者其他适合建立数据存储时，进行初始化一个仓库，有利于数据存取。
框架流程
一般而言，通过外部调用打开Page，Page中主要存在一个对应功能的Presenter。Presenter负责进行目标功能的窗口初始化，包括生成目标预制体，根据数据生成对应模型，如果有需要，存入仓库。然后对不同组件进行事件的注册（如果有的话）。创建dispose方法，并在其中调用所属组件的dispose方法。制作UpdateView方法，以实现组件复用而无需重复生成。在UpdateView方法中调用每个子窗口的UpdateView。
当View层的组件被触发，例如button或者Scroll等事件，将会传递到Presenter层，Prensenter层将对该次事件进行逻辑处理，如果需要用到数据，则会从仓库或者已持有的数据列表进行获取。如果此次事件将会打开新的页面，则会调用生成新页面的Page，该Page将会生成下一个Presenter，然后将当前Page作为上一个Page。（这里的Page有点像链表，总会打开最后一个，如果Page执行的是关闭，则会打开上一个Page，这个过程是不同功能间的切换，如果是同属一个大功能子功能，那要考虑好是以Page形式，还是以Param方式实现）
最后的碎碎念
这个MVP框架其实并不是特别完整，因为有的时候需要多层的处理，一层的Prensenter有的时候确实显得力不从心。不过在绝大部分时，这个结构时很好的处理方式。还有就是View层，其实理论上是要将所有逻辑归到Prensenter层，但有的时候可能有人会偷懒，说一点点的小功能还是没必要这样大动干戈，也有这样的情况，但最好还是将功能还到Presenter层，虽然会复杂点，但是各司其职的结构更加整洁吧。
