MVC模式随着规模进一步扩充，最初的大循环构造终于没法满足日益复杂的需求了。
规范的MVC模式被引入，经历了一次大的重构。
数据中心作为Model被独立出来，保存着当前最新的数据。
View被放在了独立的任务中执行，定期从DataCenter轮询数据。
用户的操作通过View发送给Controller，进一步调用硬件驱动执行。
硬件执行的结果从驱动到Controller更新到DataCenter中。
界面，数据，命令三者根本解耦。
ResultManager成为DataCenter的一个组件，View不再直接与其通讯。
文章相对比较长，字数比较多，大家可以先打开头像关注我，之后慢慢看，///插播一条：我自己在今年年初录制了一套还比较系统的入门单片机教程，想要的同学找我拿就行了免費的，私信我就可以哦~点我头像左下角黑色字体加我也能领取哦。
最近比较闲，带做毕设，带学生参加省级或以上比赛///MVC模式的引入，第一次让这个产品了有真正意义上职责明晰，功能独立的架构。
大量类似模块，低效的复用到上一步，作为一个单独的嵌入式设备，其架构根本能够满足需求。
但是随着市场的扩展，越来越多的设备被设计出来。
这些设备虽然执行的详细测量任务不同，但是他们都有着同样的操作方式，类似的界面，更主要的是，它们面临的问题领域是相同的。
长期以来，复制和粘贴是唯一的复用方式，甚至类名变量名都来不及改。
一个错误在一个设备上被修正，同样一段代码的错误在其他设备上却来不及修改。
而随着团队规模的扩充，甚至MVC的根本架构在一些新设备上都没能遵守。
最终框架被引入了这个系列的产品。
框架确定了如下内容：1.MVC模式的根本架构2.窗口管理器和组件布局算法3.多国语言方案（字符串管理器）4.日志系统5.内存分配器和内存泄露检测远程控制客户希望将设备固定安放在网络的某个位置，作为“探针”运用，在办公室通过远程控制来访问这个设备。
这对于原本是作为纯手持设备设计的系统又是一个挑战。
侥幸的是，MVC架构具有相当的弹性，早期的投入获得了回报。
TL1 Server 对外提供基于Telnet的远程控制接口。
在系统内部，它的位置相当于View，只和原有的Controller和DataCenter通讯。
自动化的TL1解释器由于TL1命令相当多，而TL1又往往不是客户的第一需求，很多设备的TL1命令初始不完整。
究其理由，还是手写TL1命令的解释器太累。
后来通过引入Bison和Flex，这个问题有所改善，但还是不足。
自动化代码生成在这个阶段被引入。
通过以如下的格式定义TL1，工具能够自动生成TL1的编码和解码器代码。
测试的难题经过数十年的积攒，产品已经成为一个系列，几十种设备。
大局部设备进入了维护期，经常有客户提一些小的改进，或者要求修正一下缺少陷。
繁重的手工回归测试成为了噩梦。
基于TL1的自动化测试极大的解放了测试人员。
通过在PC上运行的测试脚本，回归测试变得简略而可靠。
唯一不足的是界面局部没法验证。
基于Test Quest的自动化工具须要在设备运行的pSOS系统上开发一个类似远程桌面的软件，而这在pSOS上并非易事。
不过好音讯是，由于框架固定了界面的格调和布局算法，基于Test Quest的自动化工具会有很高的识别效率。
小结从这个现实中的嵌入式产品重构的历程能够看出，第三步引入MVC模式和第四步的框架化是非常重要关键的。
成熟的MVC模式保证了后续一系列的可扩充性，而框架则保证了这个架构的在所有产品中的精确重用。
总结本文是针对嵌入式软件开发的特点，探讨架构设计的思维和方法。
试图给大家提供一种思想，启发大家的思维。
框架，自动化代码生成和测试驱动的架构是核心内容，其中框架又是贯通始终的要素。
有人问我，什么是架构师，如何才能成为架构师？我答复说：编码，编码，再编码；改错，改错，再改错。
当你觉得腻烦的时候，停下来想想，怎么才能更快更好的完成这些工作？架构师就是在实战中产生的，架构师来自于那些勤于思考，懒于反复的人。
对单片机感兴趣的朋友可以找我，我录制了一些关于单片机的入门教程，有需要的童鞋找我拿就像，免费的，私信我“林老师”就可以拿～点击打开我的头像就能领取。