系统模型、数据库和程序代码

   系统模型好比是一个房子的框架，而代码则是填充这个框架的砖瓦。作为一个使用者看到的只是砖瓦，但是对于建造房子的人，它们是融为一体的。而且，在写代码的过发现了一些以前不曾想到过的问题，这反过来修正了最初的模型，二者真正起到相辅相成的作用。代码中用到的各种丰富的技巧，包括客户端代码的技巧，应该仔细体会这些技里很多地方只做了逻辑上的说明，对于小技巧的使用没有展开讨论。大量使用了存储过程来处理数据库操作，这些过程提供了灵活的功能强大的处理能力一用ASP代码来实现这些功能是不够灵活的、低效的甚至是困难的。应该尽可能地用存储过现数据操作——加上数据库的规范化设计，这里已经超越了ASP的界限，深入到了数据库领域，但这是必要的：缺少强大的数据库支持的“数据库应用程序”是没有竞争力的。一个好的软件系统应该是系统模型、数据库和程序代码这三者的紧密结合。
   系统模型是在系统分析和设计的阶段做的，在后面的编码过程中，会发现最终编写的代码和模型并不能完全的对应来。在一个小系统中是这样的，因为不可能一开始就将模型做到很完美。但是它确实指导了建立整个系统。编写代码过程中，要不断地回过头来查看这个模型，特别是在做完一个完整的功能部分或者是遇到难以实现的部分的时候。它建立了一个实实在在的框架，同时不断地检查：和审视它，改进它，最后的结果是，在编写出完整的代码以后，整个模型才真正完善了。UML鼓励沟通，反对封闭，主张各个阶段的信息都能够自由的流动，而编写代码无论如何是整个系统建设中的最实质性的环节，没有理由不让这一阶段的信息反馈到模型中去。事实上，只有有了实现系统功能的代码，只用动手去编写实现功能的代码，才能真正体会到系统建模的关键所在。
   所以这里不提倡过分的将过多的时间花在建模上面。当然，必须反对对将要建立的系统没有足够的认识就仓促地去凑代码。至少对于中小型系统(这里遇到的多是这种系统)，这种思想是很重要的。
   这里花了相当多的时间来构建系统的数据库，把数据库当作是系统实现的基础。如果说模型是框架，代码是砖瓦，那么数据库就是坚实的地基。在数据库应用程序中，一切实在的功能实现都依赖于数据库操作，都是建立在数据库基础上的。而很多人，特别是许多个人编写ASP时往往并不注意这个基础，而是直接凑代码。在他们编写的代码中，往往可以看到很丰富的小技巧和复杂的逻辑(不规则的代码使得这些逻辑更加难以理解)，却不能一眼就理解整个逻辑和结构。而——个好的(易于操作的、功能强大的、高效的、健壮的、安全的和易于维护和扩展的)系统的实现应该是简单的。这种简单表现在良好的和合理的设计、性能优越的数据库支持、代码的模块化、功能单—和风格良好等方面。在建立的数据库中，从系统模型出发，对每个表(甚至每个字段的数据类型)、每个视图和每个约束等都进行了比较细致的设计。这样的数据库是高效的、安全的和方便操作的。不仅在编写代码时更加方便快捷，整个系统的质量都因之得到保障。
   代码的规范带来很多实际的好处，以至于能够在很短的时间内完成实现和调试的全部。可能在许多代码段中可看到下画这一行代码：
   debug(sql)
   这往往跟在一个SQL语句后，而在数据库操作执行之前。这是因为在写代码的过程中得到系统关于数据库操作的出错提示，有了这一行代码，可以很方便地将SQL语句写到调试客户端，然后关闭可能的数据库连接，结束当前页面。有时一看就知道问题的所在，而有时虽然不能—立即看出来，但可以把写在浏览器中的SQL语句Copy到SQLserver2000的查询分析器中去执行，它立即能给出最详细的错误信息。这种调试往往是成功的。这样的成功体现在编写代码的方方画画，这里才能快捷地开发好的软件。
   任何一个软什都有不足的地方和可以改进和扩展的地方，而一个好的软件使得改进和扩展工作相对容易。