这篇文章主要是详解VFPAED架构， 相信很多人一听到这个词，就觉得很陌生，是的，这个架构是我花了很长的时间研究出来的,
后来又经过团队的多次讨论，才最终确定这个架构。
相信很多人都知道MVC、MVVM、MVP等等，这些都是业内比较著名的架构模式。
为什么要架构呢？我觉得主要有2个原因。
1.避免技术的复杂性所带来的软件维护困难问题
2.降低软件开发的人力成本
其中第一点，我们需要从以下几个方面来看：
(1)项目的需求是不断变化的，新增的需求可能会增加系统复杂度，也可能破坏原有架构
(2)一般项目都是由团队共同完成，团队如何进行有效协作是一个值得考虑的问题
(3)一个完整的项目系统，一般来说会使用到多种技术、多种框架、多种工具，更会涉及多个平台，从移动端/Web前端到Web后端
其实第3点是更高的架构层次，不再仅仅局限于一个软件的架构，而是一个系统的整体架构，今天我们就暂时跳过第3点了，今天的正题是一个软件的架构。
对于第二点就没什么可说的，如果每次需求变更都会引起架构变更，那程序员得累死了，接下来开始谈正题！
我是一个.NET Web和Android的开发者，当然也做过几个Java Web项目，以及Python Web项目
所以今天要讲的架构不会是针对某个特定平台，而是一套通用的架构模式。
我做了七年开发，在最近四年来，我一直在研究如何架构好一个系统软件，
我有个朋友是做设计的，我和他讨论过生活中充满设计，当你在思考今天要吃什么的时候，你已经开始在对你的生活进行设计了，
每个人的设计都是独一无二的，即便做出了相同的决定，但想法是不同的，生活中的处处充满设计，这是个充满设计的世界，
每个人都是一个设计师，但是每个人擅长的领域也许有所不同，在这四年里，
我尝试过很多种架构模式，但在我们团队的某个项目中，都存在很多问题，这让我很烦恼，
因为那个项目足足有135万行代码，每次重构对于我们来说都是地狱般的煎熬，这让我们意识到，
研究出一个可在开发进行时进行变种的架构模式刻不容缓，于是我开始了不断的尝试，
结合我一直在学习的易理知识，以及对历史变迁的了解，在我的脑海中已经形成了一个观念：分而治之
于是经过不断的尝试和改进，最终确定了VFPAED，即View-Framework-Provider-Action-Event-Data
View: 一般指GUI，即用户界面，只负责处理用户在界面的行为和事件交互
Framework: 框架层，将一个软件分解为若干个大体框架
Provider: 功能提供器，多个功能器组合起来为每个框架提供相应功能
Action: 动作，是用户行为的抽象，用户的每一个操作都是执行一个动作
Event: 事件，调用功能或执行动作可能触发事件
Data: 数据，在调用功能、执行动作、触发事件的过程中少不了数据的穿插
那么，如何将以上几个部分组合起来，在正式开始之前，需要注意的一点是：
以上是VFPAED的完全架构，当然就还有很多种非完全架构变体，在后面的文章中将会详细分析，
并进一步分析如何根据程序规模进行非完全架构到完全架构的变种
