前面先后描述了我设计的两版架构：原始框架和以协议为核心的框架。在各自的生命周期内，这两版架构都发挥了应有的作用，也都存在着缺点。
在我接收公司软件部的一年之后，随着项目的增多以及业务、技术的成熟，我决定进行第三次架构设计。推动这版架构重构的直接原因是：和工程部及用户的对接难题。
在一个项目中，除了了解核心逻辑、用户业务逻辑之外，还有很重要一部分，就是用户的数据。比如用户有几个房间，每个房间几个设备，都是什么型号的设备，这些设备的控制代码是什么，回复是什么等等。随着平台的成熟以及项目的增多，核心逻辑部分会日趋稳定；业务逻辑部分，服务器和客户端都分离出了Application层，而且下层的模块及控价都提供给了Application层丰富的接口；并且随着项目经验的增多，业务逻辑的复用、模板化工作也日益成熟。因此，完成一个项目的技术瓶颈，从最初的核心逻辑转变到第二版框架的业务逻辑，然后到了第三版框架的数据对接。如何快速、准备的完成数据对接，并让数据对接工作的非开发端（工程部们端以及用户端）能顺利的完成；以及如何在版本升级中快速的更新数据、在调试中查找数据问题，便成了新的重心。
以数据为中心的框架，我分割成了几个要点：1是静态数据以数据库为中心，2是控制命令数据库化，3是回复数据的注册机制。
服务器端的架构图如下：
上图是服务器端的第三版架构，可以明显看出，其中规模最大也最复杂的变成了数据层。
1、提供两种方式的数据录入，一是Excel表，一是浏览器。前者用于对接简单规范的数据，因此方便和用户及其他部门对接；后者对接诸如屏幕拼接、开窗漫游数据等复杂数据，由软件人员或经过培训的工程人员完成。这样就大大提到了数据对接的效率，并减少了错误（两个工具中都有错误检测）。
2、数据库中间件是整个体系中的重要部分。在本框架的客户端中，客户端不在内存里面保存大量数据，而是直接对远端数据库进行访问；而在移动端情况下，因为设备、无线网络等原因，直接的数据库访问并不稳定；因此提供了中间件，通过服务器进行转接。此外，中间件能实现数据库的双机热备。
3、在有了足够激烈的情况下梳理了业务模型，并基于模型设计了统一的数据库表结构。虽然小型项目用不到所有的表，但只要用到表的子集，以及表的部分列即可。这样统一了整个数据设计、编码和逻辑部分。
4、为CTable类族提供了工具类，辅助开发。值得一提的是Json的应用，在数据库中只允许int、String及bool三个类型，诸如Vector和Map均转换成Json存储。降低数据库开发复杂度。
5、 建立设备驱动。通过固定的表、占位符加参数拼接的方式，记录所有设备的控制代码。
此外，在上面结构中还可以看到
1、应用层的分离。并提供基本模型。
2、提供设备模拟器，通过读取数据库表、进行IP和端口映射、建立虚拟设备、模拟实际设备行为，来辅助测试大规模项目的逻辑。效果良好，节约了现场调试和Debug的大量时间，并逐步让整体代码更为稳定。
3、提供设备代理模块。设备代码模块也比较复杂，值得一提的是回复注册机制以及设备状态注册机制。通过默认注册以及设备状态注册的方式，处理设备的回复，并将回复数据处理完毕后提交到应用层；同时，设备状态也会实时广播到所有客户端，与控件化的客户端（每个空间带Id）配合使用，减少了代码量。
上文分析了服务器架构演进的第三版（估计会是最终版），下一篇会分析与之配合的客户端架构部分。