这篇文章主要说明从小型项目到大型项目中，如何合理地扩大项目架构，使其能够支撑日渐增多的代码，
可以发现，其实VFPAED架构就是VX架构，V就是View，而X就是其他，也就是说对于GUI应用，
本质上只需要分解为两层：View/Other，但是想要更合理地架构软件，就需要对VX中的X进行合理拆分了，
VFPAED中，FPAED就是对X的拆分，前面对VFPAED的介绍看起来很复杂，是正常的，因为那介绍的是完全架构，
而对于非完全架构，就有很多种可能了，下面我们就来看如何从最简单的非完全架构逐步进展到完全架构：

书契所使用的并不是VFPAED的完全架构，从上一篇文章我们可以看出，每个Framework都要储存自己的Data/Provider/Action/Event，
很显然我们说过，Data是极少的，而书契分为了Common/Project/Code/Plugin/Cloud 5个 Framework，
将Data分散在5个Framework中会造成很大的浪费，并且结合书契的实际情况，其Action和Event数量也没必要分散到5个Framework中，
于是我决定增加一个全局框架(GlobalFramework)来储存所有Data/Action/Event/Provider。

VFPAED完全架构由6个部分组成：

这篇文章主要是详解VFPAED架构， 相信很多人一听到这个词，就觉得很陌生，是的，这个架构是我花了很长的时间研究出来的,
后来又经过团队的多次讨论，才最终确定这个架构。

相信很多人都知道MVC、MVVM、MVP等等，这些都是业内比较著名的架构模式。
为什么要架构呢？我觉得主要有2个原因。

1.避免技术的复杂性所带来的软件维护困难问题
2.降低软件开发的人力成本

书契是由我们团队打造的新一代面向多领域、一体化的开放工程平台，
其支持以插件的形式向书契平台内集成多领域、多类型工程的管理和开发功能。
有人说“你们都搞了结绳了，为什么要搞书契”，这其中有很多原因。

前几天用AS的Statistic统计了一下结绳4.0的代码行数，结果让我大吃一惊（其实也在意料之中），
毕竟我们团队三年持续开发，有个100多万行也是正常的，来看具体数据：

如果我们学过Lua/Python语言，应该知道它们是支持长文本的（当然，在Java新版本也是支持长文本的，不过我还在用Java8），
举例：

相信大家都学过C语言（应该是大一计算机相关专业必学语言），也写过冒泡排序，其中有一段代码我觉得不是很方便，
那就是交换两个数组成员的值，需要用swap函数，或者定义临时变量用于交换（伪代码）：

相信学过C++/Kotlin的同志都知道，这两门语言都支持参数默认值，这其实是非常好用的，所以结绳中文编程也引入了这个特性。
举例（伪代码）：

相信学过C++/Kotlin等支持运算符重载语言的同志们都知道运算符重载在代码编写过程中是十分方便的，举个反例：
Java无法在代码层面实现运算符重载，所以大整数之类的使用起来就稍显繁杂：