Event-Model-View-Controller 架构

MVC架构写的程序泛滥的厉害，但是有一个课题，耗时许久无法妥善解决。

课题是如何在系统运行过程中动态调整全局字号或者控件尺寸。

看似简单的不能再简单的全局变量赋值后再调用问题，

却因为Android或者Flex等高交互方案的UI持久化随意性而变得困难。

Android的Activity的生命周期最好不要强行控制，

应该让系统来决定是不是进行销毁，这样条件下，

无论Activity主线程或异步线程内，反复调用全局的布局尺寸变量并更新UI，

对系统的性能的影响随着布局的复杂而线性提高，

同时每个Activity的结构都会因为这个要求同时增加类似的处理机制，

总体来看，此方案可行且有实践经验，但是雷同代码和重复机制，真是愚蠢。

如果在Activity之外统一进行布局尺寸的更新控制，

将会是一个全局C读取M控制所有的V，

这个样Controller就不是MVC里面的C的概念了，

同时会因为UI持久化未知性，会增加非常多的非空判断，

而且这样的C也会因为V的增多而复杂。

反观现有的比较好的MVC实践，都对Runtime的Event（Flex）或者Delegate（.NET）有一定的依赖，

使用Event机制，解决的也就是我面对的全局通讯问题，一个点发出变化指令，

所有在持久化状态未被销毁的UI或者Class，随之响应的机制。

从而，提出EMVC（Event-Model-View-Controller ）架构，

在Android中引入Greenbot的EventBus，在Flex里面引入CommandDispatcher，

设定一个全局EventBus或者CommandDispatcher，

所有需要响应的地方设置OnEvent或者EventListener，

一个地方发出Post，管他其他地方在哪里，活没活着，能听着的，都会有响动，

响应的地方只需要根据Event里面的信息决定哪些需要变化就可以了。

不仅解耦，关键是省心省力，各管各的。

提出的EMVC相比原有的MVC架构，仅仅是将原来依赖Runtime的Event机制包含进来，脱离对于语言平台的依赖。

原有的MVC架构思路已经很好的划分了程序代码之间的运行机制，EMVC仅仅是在通讯这一个问题上向前走一步。

就像一个企业的部门划分一样，销售、生产、财务各司其职运行良好，但是随着业务总量的增加，

各部门间多对多的通讯机制难免越加复杂和指令多头发布，也会出现等着发呆不推不动的员工，

增加一个筛选、转送、协调各部门间指令信息的专门机构就十分必要。

三星管这叫秘书处，前清叫军机处，日本英国叫内阁，

总之，买卖大了，人多了，大家一起喊话太乱了，还是协调一下的好。