动态站点后台建设的一点思考

    最近“大事”比较多，一来春节在即，二来大雪封邦，等等；公司网站部分做了很多应时的“内容页”，但建设的人不是技术人员，而是普通的编辑人员：他（她）们着实很辛苦的。

    偶尔伤感到，是不是我们有些失职了？还是圈子里默许这样的“茹毛饮血”？我向来以为那些个互联网资源都有一个强大的后台，所有用户看到的内容，是由编辑人员通过较友好的管理工具制作出来的；但如今亲眼见到含具体内容的“静态页”手工绘制、发布，令我“不寒而栗”。

    出现这样的情况，大体是因为“应用”的即时、瞬时性，而开发人员视能力、人员数目的不同需要投入不等的时间造成的；出于成本的考虑，或许在流程上某些公司团体选择了简化、原始的内容制作方式。可我还是觉得，主要矛盾在于“后台”的开发方式。

    如果前台制作需要一周的时间，那么后台将耗费两周甚至一个月的时间，后台对于动态数据的支持，要求严格的自测甚至一定的功能扩展性；我所见到的前辈们的“页面管理后台”，多以“前台 <=> 数据库 <=> 后台”的形式展现。这种设计在逻辑上颇能服人，所谓“扩展性”多体现在数据库端表、字段的预留以及松耦合等。可惜我并不看好他。

    一段时间以来，我在实践一种“前台数据库 <=> 前台页面 <= 后台系统 <=> 后台数据库”的设计思想；这样的做法无非是将“用户交互数据”与“页面展现数据”隔离开来，前者是“前台数据”，后者为“后台数据”。对于某些应用，前后台数据会有交叉。这样做的好处，使得“后台适配器”管理模式成为可能。下面一一解释他们之间的具体关系。

    “前台数据库 <=> 前台页面”，对于纯静态内容页，数据库可以抹去；动态交互站点，表示前台的操作更新到数据库，而数据库亦反馈数据给前台更新页面。过去、现在以至将来，这种方式或许都不会变。

    “前台页面 <= 后台系统”，对于静态或动态前台内容页，其源码都由后台系统生成（而不是编辑人员手工制作）并“发布”，使得编辑人员可以花更多的时间勾勒页面的具体内容，而不是去了解甚至学习像html这样的标记语言。即时、瞬时的页面需求，可以调用后台系统的前台页面模板，继而按系统提示编辑用户可见内容，并发布页面。

    “后台系统 <=> 后台数据库”，显然，后台数据库里存放着各类“前台页面”的源码信息以及各类模板的源码信息；他的特点在于“适配器”功能，即后台开发不再是用VS2005这样的专业软件，而是在这个“后台”进行“新后台”的开发。乍看挺像“自学习”的软件；由于引用了已有的“页面生成、管理”过程，使得测试变得轻松、愉快（而不那么紧张、严格）；最重要的，细微的需求变更可以直接在“后台”重开发完成，而不要走完所有“开发 -> 测试”等管理流程（我想多数人还是了解，那种软件重复打包、提包、部署的过程，即便是补丁，是很熬人的；软件人可能都讨厌重复的人工劳动吧）。

    类似这样的“站点建设”专业软件我倒是见过的（功能没仔细推敲过），而且貌似更强大（各种站点数据统计功能）、商业化（收费与售后），只是成本以及可控性让相当一些企业有所顾虑吧。

    搞软件的大体都是“懒人”。我这样做，无非想要简化后台开发方式，特别是，让“界面开发人员”与“后台开发人员”工作隔离。如果有一天，某前台站点的“界面样式”等需要变更，可由界面开发人员在后台进行更改操作，而无需后台开发者的参与（传统方式，界面开发人员打包给后台开发人员，后台开发者再打包、提交等）；另外，面对前台页面内容类型、编辑模式的变更，可由后台开发人员在后台更改相关前台页面的源码数据（参数），而尽量少的利用VS2005等工具重开发类似后台，减少开发时间、规避部署出错等风险。

    考虑到项目还处于实践、完善阶段，更考虑到公司相关站点的安全性（现在看来，这点愈为重要），本文没有演示现有解决方案的源码甚至类图关系。惭愧的是，文字表达晦涩难解，怕只怕过些日子自己都读不通顺，那“笔录”算是白做了；留点念想吧。

    望自己再接再厉，使得成品的可用性真如自己预想的那样，彼时或许大脑一热，还真敢“开源”了。下篇文章想写《动态站点静态化以及合作形式的一点思考》，是对站点性能提升以及与其他公司合作方式的小结；注意了，我所指的性能提升，绝不是“缓存”的概念。呵呵，这些个好像都是明年的事了。

    朋友们、网友们春节愉快！