这一节先聊聊上一节所描述的框架的优劣。
首先，任何一个框架都不可能没有优缺点；所以只有合适的框架，没有最好的框架。个人觉得，在实际工作当中，我们应该追求的是可接收的框架，而不是最好的框架。
上一节的服务器框架如下图：
这个框架的优点包括：
1）易于理解。这看起来不像是一个优点，但在实际工作当中，说不定还是比较重要的一点。以我当时的情况，刚组建团队，团队磨合不够好，对大家的个人能力心里也不太清楚，所以能顺利的说服大家，把框架解释清楚，让大家齐心协力往前走，还是挺重要的。
什么是易于理解呢，简单点说，就是“功能导向”。跟大家解释一个功能一步一步怎么做，总是很容易的。但如果把大量功能集中在一起，分成抽象的若干层，又来一点数据啊通讯啊各类同步或异步技术，很多同事就未必理解得了了。如果同事理解不了框架，那一些模块的关键代码肯定得自己一个人写，更重要的，让同事们写功能代码你也得花大量时间去审，代码维护升级和优化都是问题。好框架的重要性之一，就是要调动团队成员的“协同作战”；如果弄到需要框架设计者一个人承担大部分编码职责，那说不定不考虑框架的实实在在功能导向反而更快更省事。
上图易于理解之处，比如说设备相关的代码，从设备控制、设备信息生成、设备类，都赤裸裸的；再比如静态信息（数据库里的固定信息）、动态信息（设备回复、系统状态等可变信息）的划分；甚至包括很多情况下不算个好主意的“全局管理者”类。
2）数据和控制的分离。这一点是大量框架都希望做到的。在上图中，数据库、设备信息生成、全局管理是数据部分的。而信息管理层：静态数据中心、动态数据中心，则是数据控制层。如果把数据和控制搅和在一起，容易带来bug，排查时摸不清是数据出了问题还是控制的问题，排查也会更为困难。
缺点：
1）功能导向。功能导向虽然让框架易于理解，但带来的负面因素太多了，尤其在可扩展性上是一场灾难。这也是上述框架所承载的项目最终重构的主要原因。
2）分层模糊，模块划分不够明确。分层和模块划分与其说是一种技术，不如说是一种“感觉”。在当时，我虽然知道自己在分层和模块划分方面做了一些妥协，但并未觉得有多大妥协，或者说未来会造成多大麻烦。但对比后续的两个版本，第一版本的服务器设计确实觉得模块划分方面做得不够好。比如数据部分在上中下三层都有；设备控制部分也松散。
上述框架历经10个版本的修正，最终迎来重构的命运。一方面，我个人习惯3个大的版本升级就要优化框架；5个大的版本升级就要重构，所以，10次升级还能勉力支持，这框架也算得上对得起我了。另一方面，从现在的眼光来看，这个框架为了团队、技术选择受限等等事务妥协太多。很明显，上述框架是无法支持我最初提出的“平台设计”的需求的，在最初，我也并未急着为平台打造框架，所以上述框架终归是给一个项目准备的，难度自然小了很多。
客户端方面：
客户端方面，框架的好处在于：
1）UI、数据及控制的分离。因为最最开始，在我框架未出来之前，同事编写的客户端代码是吃过亏的，调到让人奔溃；和用上述框架写的代码一比较，不得不承认上面的框架起了大用。所以，从一个侧面反映UI和其他部分的分离是多么重要；只要做到了这一点，中小规模的客户端编程就不会差到哪里去。
所以，对前端框架设计、客户端框架设计感兴趣的同学，认真看几个MVC或MV有关的案例，还是挺有好处的。MVC(以及更轻量的MV)在UI相关的大大小小设计里这么流行，经久不衰，也是有它的道理的。
2）元模型和模型的划分。元模型，是指服务器的数据到来之后的简单处理和存储；模型是在元模型基础上，按照业务划分的数据群体。元模型加模型，取得了一种服务器来的大量数据处理难度，和对M及C层支持难度的折中；这种方式也易于编程和理解。
在模型层，所有模型类的API我又强制性的让同事们分成了支持View的API接口和支持Controler的API接口，进一步的把数据给划分清楚。而一旦数据部分掰扯清楚，对于很多的客户端编程，难度就不会很大了。
3）自定义组件层。自定义组件层，是在Qt自带的Widget组件基础上，根据项目需要，我们自己优化的诸如按钮、按钮组、标签、回显控件（从网页上每隔一秒取张图）、拖动控件、视频控件等。事实证明，磨刀不误砍柴工，这些控件复用了很多次，也体现了他们的价值。
上面框架的劣势：
最大的劣势，就是太过重量级。分层太多，显得笨重。这样会加大代码量。
后续的几个客户端框架，都会削弱上图的层级。再最终，我把一个MVC为核心的框架转化成MVA(MV+Application层），取消了独立的Controller层。
对第一版框架的分析就到这里。后续会分享后两个版本的框架，希望大家能从正式的框架演进案例中，对架构设计这个行当有更多更深刻的理解。