PHP应用程序设计：一个实际的例子（1）

设计一个应用程序时，你先考虑的是这个应用程序要做什么。在p h p C h a t中，我们希望这个应用程序能够提供基于网络浏览器的聊天服务。
聊天应该具备以下的特征：
• 实时的同步聊天：没有信息的中断，也不需要刷新
• 不需要客户端的程序：浏览器面对的应该只是纯H T M L（最后也可能是J a v a S c r i p t）。
• 有网络功能：它应该能够连接到用于聊天的对话框。
• 通用性：对目标系统的配置作尽可能低的假设，对系统的需求要尽可能少。
• 设计没有强制性：程序代码和页面布局是分离的。
• 易于使用和管理。
• 对用户数目和聊天室数目没有限制。
一旦你了解了这些要求，而且也知道了你的应用程序需要做些什么了，你就要估计一下情况，设计一个更加详细的关于应用程序该如何布局的概观表。

花一点时间把所有的要求都写下来。这是非常有用的，特别是作为以后的备忘录。替用户设计一个应用程序时的步骤叫建立技术规格（ creating the specification）。这个时候，用户仍然可以影响应用程序的整个布局。这是非常重要的，因为设计的应用程序必须满足用户的所有要求。要不然你的程序就不会被用户所接受。

需要应用程序的用户，通常他们自己没有多少设计类似应用程序的专业知识，这也是他们为什么要雇佣你的原因。当你和用户讨论各种要求时，如果他们提出了错误的方案，你要耐心的引导他们。例如，如果用户说：“我希望这个聊天程序能够全屏显示每一个聊天者的图像，至少每秒钟刷新一次”。你可能会有一个这样的相反的建议：“试着在每一行后面使用非常小的视图是不是会更好一点呢？大部分聊天的用户根本没有足够大的网络带宽去显示全屏的图像”。
但是要小心一点，绝对不要坚持你的观点（除非用户要求你实现根本不现实的功能）。总之，用户是花钱请你实现他们的想法。为了避免失去与用户的业务联系，你可能不得不接受去执行一个不太好的解决方案（当你发现不能引导用户同意使用正确的方法时）。以后当用户发现用他们的方法不能够实现的时候，你再来改变它。
在这个项目中，你将扮演项目经理的角色，但董事长却是你的用户。既然我们都是很不错的用户，我们就不应该坚持要详述这个应用程序更深的细节问题了；我们就把设计的剩余部分交给读者你了。无论什么时候，对于本章涉及到要作出选择和决定的地方，你都要静下来尽量作出自己的选择，仔细地估计所有的情况，然后把你的结果和本书讨论的结论相比较。

比较技术环节

在开始考虑程序代码的布局之前，这中间有一个我们不知道怎么称呼的步骤，只知道它“将所有的东西聚集到一起”。这是一个介于整体构思和技术规格/代码布局阶段的步骤—指出了内部的工作情况以及基于这些构思和技术规格的是什么。
为了把这一点说清楚，让我们回到最开始的部分，提出以下问题：
• 我们想要建立什么东西？
• 我们如何才能建立他们呢？
• 是否已经存在能够实现我们构思的方法？
• 是否有相似的几乎具有相同功能的系统存在？
• 如果是这样的话，我们能不能从别人的设计那里借鉴什么东西？
• 我们是否能够再利用外国的技术？有没有可能把它们添加到自己的系统中去？
第一条非常容易回答。现在我们想要创建一个聊天系统。怎样创建呢？用P H P和某种方式的服务器端—此时此刻，我们知道的就这么多了。
有没有现成的聊天系统或者某些相似的东西？事实上有。你可以马上翻你的书架—“t a l k”命令允许你和网上的其他人聊天，它创建了一个有效的网络连接通路（或者一个局域连接），如接，这大大地减少了网络堵塞。
虽然I R C要求在每一个参与聊天的用户系统上安装特殊的用户软件，但是我们可以利用这种要求，使其转化为我们软件的优势：我们为什么不在服务器端提供一个用户软件，然后使用一个H T M L接口把它抽象化，并且允许每一个用户通过H T M L的客户端获得这些软件呢？这将使我们可以控制用户所做的事情（每个用户都要求使用我们的H T M L客户端）。另外，我们拥有现有网络系统的所有优点：可靠的用户软件、已经得到验证的理论、成百上千的工具等等。我们甚至可以允许用户使用他们自己的客户端软件—这是在大多数情况下都是应该避免的，因为我们想创建一个“封闭”的聊天网络。在一个封闭的聊天网络中，我们知道每个用户能够访问你的网络的所有方法。通过在详细的初始化设置中限制这些访问的方式，可以大大的减少被黑客攻击的危险。
这直接导致了一个问题，我们到底需不需要像I R C这样的协议呢？或者仅仅只使用一个由数据库驱动、有远程同步处理特征、能够满足所需网络功能的协议就已足够呢？

这样的问题在每次规划一个应用程序的时都会出现，而且还会经常出现。你要确信已经把所有类似问题都解决了，而且确信在开发的以后阶段都不会出现问题。你必须能找到出现这些问题的地方；否则以后你也许不能解决他们（还可能使你的项目最后变成一堆垃圾）。一个好的项目应该是一个没有垃圾、没有不确定性、没有不一致性和不可无法预料结果的项目。确保在规划环节之后，你可以获得一个稳定的而且是完全符合预想的解决方案。
所以，让我们回过头来回答这个问题：我们需要一个像I R C这样开放的（可能也是复杂的）协议吗？还是应该坚持使用一个传统的数据库方法？找出答案的最简单的同时也是最有逻辑的方法—进行正反比较，然后选择有最好结果的一项。
将I R C作为一个协议执行到聊天系统中，将引入极其复杂的事情，因为协议过程——网络协议过程需要非线性的程序代码，而实际上P H P并不支持非线性代码（为了对网络信息起反应，我们需要一个基于事件处理的系统）。紧接下来的问题就是我们需要一种有效的处理信息交换的方法。也就是说处理来自用户的信息和替用户发送信息（遗憾的是收发信息通常不是用同一种方式处理的）。当然使用由数据库支持的解决方法也同样存在这个问题。但是由数据库支持的解决方法不需要协议处理。许多数据库本来就被P H P支持，同时那些不被P H P支持的数据库也很可能会被O D B C间接地支持。为了获得能用于网络聊天的对话框的功能，我们只需要创建一个能够在两个对话框之间同步工作的工具即可（除非你只想运行一个能被所有对话框同时访问的中心数据库服务器）。
你选择哪一种方法？
最后的选择：p h p C h a t是基于I R C的，下面是其原因：

• 使用一个数据库，相当于引入了一种所属类型，私有协议不能连接其他的规范系统。在讲究互用性和互连性的时代，这不是一件好事情。
• 一个功能完好的I R C库（也就是p h p I R C，请参看w w w. p h p w i z a r d . n e t / p h p I RC），把对I R C网络系统的访问抽象成一套易于使用的应用程序接口的函数—在代码的复杂性方面使得I R C的处理与数据库的处理相当。
• 现存的I R C服务器软件处理所有用户管理程序的琐碎问题，还管理可靠信息转送和路由选择等问题。这些软件已经被传播了很长一段时间，并被证实能够很好的工作。另外，它还能用于所有的系统类型。
• IRC非常容易升级。在网络使用的颠峰时刻，如果服务器A加载时出现了问题，或者出现了未知的事件，仅仅只需连接到服务器B上，动态地建立一个服务器连接，然后进入现有的聊天室（I R C允许你这样做，而且是全自动的）—现在你就可以给额外的用户提供另外一个拥有足够空间的服务器。