以数据(结构)为中心的架构设计

数据在任何产品的开发和设计中, 始终要摆放在首要位置。 跟数据贴近的两个概念是: 数据库, 数据结构. 这两个概念最终都是数据结构。数据库的表结构就是数据结构。 程序 = 数据结构 + 算法 这一经典的公式, 导致我们误读为: 数据结构和算法的地位是等同的. 但实则不然. 对数据结构的态度已经决定你的架构的优劣。 本文想通过J2EE的项目和普通的C/S架构的项目, 来说明一下, 数据结构为中心的思路, 带来的架构上的优雅性。

 

第一:关于软件产品, 数据结构, 算法的一个简单的比喻

软件产品的核心, 都是对数据进行处理。 举例几个常见的例子: 人力资源管理系统, 最终的目的, 就是将公司的人力资源数据做一些必要的处理, 如增加, 删除, 查找, 涉及到人事变动, 如晋升, 离职, 这些, 都是对人力数据的调整; ERP管理系统, 对公司的进出口数据进行管理; Google公司, 它自己的核心理念, 也是对全球数据进行整合。用户传入查询的数据信息, Google网页将返回查询结果的数据信息.... 等等,这些, 都无外乎数据。 所以说, 软件的核心是数据处理。

 

数据在其中的重要作用, 可以用日常生活中的:"巧妇难于无米之炊"来形容。 数据就相当于这里的“米”.  我们提到的数据结构, 就是如何存放这些“米”, 可以用不同的容器: 比如锅, 电饭煲, 微波炉等. 存放数据的容器, 就是我们的数据结构。

 

数据结构的存放方式, 直接影响到数据的处理方式, 同样用“米”来做比方。 假如我们的软件是一个将“生米煮成熟饭”这样一个数据处理系统， 我们有三种方式：

 

方法序号                     数据结构                   算法                              应用范围和效果

1                                普通的铁锅                 燃气灶加热                      不常用, 不方便控制

2                                微波炉                       通电加热                         基本不用,  耗电大, 时间太长

3                                电饭煲                       通电加热                         常用, 易于控制

 

 

这里想传达的意思是, 达到目的"把饭煮熟", 可以用很多方式来实现, 通过组合数据结构和算法, 便可以达到我们的目的.

 

为了达到更好的目的, 当然我们可以优化算法, 我们可以这么做:

第一种方法, 用普通铁锅, 我们可以调节火焰的高度, 增加火焰的利用率， 比如用一个圈圈盖在火焰的周围，使得热量集中于铁锅

第二种和第三分钟方法, 我们可以加大电压, 增加电流的方式, 实现快速加热

 

当然还可以修改数据结构,

第一种方法: 买一口更好的锅, 受热更好的镍铁合金锅, 锅底是凸型的, 更容易受热

第二种和第三种方法: 买更好的电饭煲和微波炉.

 

如果是你, 你会选择调整盛米的容器, 还是调节加热的方法呢! 如果你不知道, 问问身边的家庭主妇可以得到不错的答案.

 

  (我想我们只会选择电饭煲, 通过通电的方式, 实现“把饭煮熟”这样的目的。 如果要优化, 我们会选择一个更好的电饭煲)

 

同样, 作为程序员的你, 你觉得在软件设计中, 应该将精力集中在算法, 还是在数据结构上?

 

(我赞同的答案是花更多的经历设计数据库和数据结构.)

 

做一个声明, 并不排斥算法设计, 但始终认为有什么样的数据结构, 才会出现什么样的算法. 脱离数据结构去谈算法, 是不可接受的。

 

 

第二:经典著述中对数据结构和算法的探讨.

这里将引用《Unix编程艺术》以及《代码大全》中, 关于这部分的理解

 

 

第三:数据为中心的架构带来的简单设计

a. J2EE中数据为中心带来的简单性

 

b. 自己经历的两次软件设计,一次成功, 一次失败。 得出的结论, 数据为中心的结构设计, 让架构更容易理解, 项目更容易维护

                              -----------------------------一个UI和数据纠结的项目.

项目介绍:

1.      功能

实现一个计算通信设备功耗的工具, 通信设备包括基站，RNC之类的产品.

2.      主要的功能

a)        16种类型以上的设备, 选择一个或者多个设备类型, 以此为基础，用户进行配置. 每种配置包含20个左右的参数. 参数之间存在逻辑关系, 比如一个参数决定另外一个参数是否出现，出现的值应该是多少.

b)       可以导入一些实际已经存在的参数文件，根据用户选择的模型，把参数填入到用户配置好的数据中。

c)       UI显示数据, 并体现各个参数之间的逻辑关系

 

d)       UI更新完毕之后，对配置完好的“数据三”进行计算的操作, 并在界面上展示结果.

e)        其它的一些非常BT的问题.

                        i.             当时该项目是某个主项目的二次开发, 带来的问题是，主项目存在较多缺陷，提供的接口非常不友好, 比如b)中提及到的xls数据源的问题, 实质上该xls是对该主项目的接口. 但里面存在非常多的无用和冗余数据需要本项目处理.

                      ii.             数据中可能存在错误信息，需要本项目去处理. 这样可能会带来一个严重的问题，数据上的问题，最终将会导致UI和计算模块出错.

                     iii.             当前项目要考虑主项目任何形式的更改. 满足维护上的简易性。

 

前后期版本架构上做了很大的改变:

1.      前期没有将XML结构的数据完全独立成一个类,而是直接用xml的方式进行解析和数据提供，即使提供了众多的方法, xml解析器根本无法代替数据结构，作为一个数据的API接口. 提供对外使用相当困难. 第二个版本,独立出一个MemoryData, 将树状结构的xml梳理成数据结构, 统一提供对外使用。

2.      各个模块，直接提供文件接口直接解耦和. 导入xls的功能, 数据立即写入文件, 当UI取数据的时候，不是通过内存获取，而是从数据文件中获取, 这样，导入功能和UI展示功能完全解耦和(可能很多人觉得，这样降低了效率, 但这个牺牲显然是值得的).对计算模块更是如此.

3.      以数据为中心的接口设计, 当主项目更新的时候, 当前项目，只需要在源头设计一个过滤器, 将格式做调整即可，后续的计算模块，UI模块，都不受影响，极大的提高了可扩展性。

架构图如下所示:

 

可以看出，整个过程，都是以数据为中心的方式进行设计, 重申一下这个系统的特点:

1.      所有功能围绕数据进行接口, 可以想象成为一个过滤器

2.      所有的功能都直接从文件获取接口，以方便彼此间解耦和重用.