总结反思

互联网时代的互联网产品开发，稳定性和快速可迭代性的重要程度可能高于其他性能，甚至是高效性。

现在看来，稳定性和快速可迭代性都基于“简单”的“代码构建”上。“项目构建”太深，范围也太广，涉及从需求分析到编程，再到测试的诸多阶段，而“代码构建”仅仅是就编程阶段的代码规范而言。而这里的“简单”，也不是狭义上的简单，而是相对简单，这种“简单”，甚至意味着可能的代码量的增加和代码本身的繁复。

首先要引入Model（模型）和Infomation（数据，信息）的概念。

Model是前后端数据交互的模型，约定。一个好的Model应该包含，且尽可能仅包含某个页面或者某个功能的全部需求字段。后台不管通过怎样的方式，得到怎样的数据，最后都应过滤处理成对应的Model，而前端或客户端等则可以在后台实现的同时进行相应页面的布局或功能的实现。所以在协同开发中，Model的制定该早于代码的实现。而良好的Model的制定，需要一定的经验和一定的“高瞻远瞩”。制定人员需要充分清楚整个功能的流程，需要对后台和前端的交互流程有清醒的把握。

而Infomation则专指后台通过各种形式分析获取的数据。通常来说，数据的最终来源包括形形色色的存储工具：缓存，数据库等，我们以数据库为例。符合三大范式的数据库设计，某种对象的基本属性（Base Infomation）该聚集在同一张表中，而对象的其他相关属性，可能分布在其他的一张或多张表中。有的时候，我们基于此对象实现某种功能，拿出该对象的基本属性就足够，而更多的时候，我们需要该对象的基本属性及与其相关的“部分”属性的组合，才足以应对绝大多数的功能需求。

简单一点的例子，比如表A的相关属性分布在表B，C，D（我们将这里的BCD称为关联表，B，C，D表中关于A的相关属性分别为b1，b2，c1，c2，d1，d2，d3）中。除去必须的表A中的所有字段，针对功能一，需要与A对应的b1，c2属性才能完成，针对功能二，需要与A对应的b2，c2，d3才能完成，针对功能三，需要与A对应的b1，b2，c1，c2，d1，d2，d3才能完成。撇开复杂的多表联合查询的sql语句，查询算法，排序算法不谈，什么样的代码能够在最大程度保证效率的同时，实现最高的复用度和最低的系统复杂度？

在下面的情况中：

1.关联表不多（1～3）

2.多数功能的实现需要的数据分布在全部关联表

3.少数功能需要的数据分布在部分关联表，但分析全部关联表不会造成可怕的性能消耗

我们可以考虑仅仅提供一个方法，方法返回的是一个对象的全部信息（Detail Infomation），包括A的Base Infomation和与其对应的B，C，D的Base Infomation。那么，如何拿B，C，D的Base Infomation呢？用类似的方法，拿出各自的Detail Infomation，再取其中的Base Infomation？我需要找一个鸡毛，你在给了我这个鸡毛的同时，还给了我一本《化学成分大全》，一本《生命发展史》和一本《十二生肖的心理特征》？别闹了～！所以我们还需要这样的一个方法，可以提供A的Base Infomation。

这样看来，我们针对特征字段对特定对象相关数据的查询方法，应该包括四个：单个获取Base Infomation，单个获取Detail Infomation，批量获取Base Infomation和Detail Infomation。上面的例子则可以通过在getADetailInfomation()方法中，整合getABaseInfomation(),getBBaseInfomation(),getCBaseInfomation(),getDBaseInfomation()来实现。为什么有单个和批量的分别？批量不是可以简单的循环单个操作吗？额，这个，针对一个问题多问几个为什么，就容易上升到人为什么活着的哲学高度……好吧，我只是不知道该怎么回答这个问题，如果你确实在从事码农的工作，还有这方面的疑问，我觉得大兄弟，转行吧，世界那么大，你该去更广阔的天地自由翱翔。

那么如果关联表很多，而大多数功能的实现不涉及全部的关联表呢？那可以根据关联表BCD写一个方法，来获取Detai InfomationBCD，再根据关联表BDEF写一个方法，来获取Detail InfomationBDEF等。

为什么不将获取到的Infomation直接传到前端，而要多一步遍历过程，将Detail Infomation转换成对应的不同的Model呢？其实通过上述的方法进行代码构建，能做到的仅仅是降低了系统的复杂度，提高了代码的复用度，不需要针对每一个需求再重新编写代码（“不重复造轮子”）。而为了降低前后端的耦合性，在后台Infomation发生频繁性变化时，前端可以不做任何修改，我们引入了Model的概念。Infomation可以出现在项目的任何位置，而Model只会出现在响应返回的层面，不管Infomation变成了什么样子，都需要重新过滤处理成原定的Model。