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仅仅是在通讯这一个问题上向前走一步。
就像一个企业的部门划分一样，销售、生产、财务各司其职运行良好，但是随着业务总量的增加，
各部门间多对多的通讯机制难免越加复杂和指令多头发布，也会出现等着发呆不推不动的员工，
增加一个筛选、转送、协调各部门间指令信息的专门机构就十分必要。
三星管这叫秘书处，前清叫军机处，日本英国叫内阁，
总之，买卖大了，人多了，大家一起喊话太乱了，还是协调一下的好。
Event-Model-View-Controller 架构,布布扣,bubuko.com
Event-Model-View-Controller 架构
原文：http://blog.csdn.net/laohliang/article/details/23735671