选择在何处运行层

本书的大部分内容我都是讨论逻辑层：将系统划分为不同的部分，以减少系统不同部分之间的耦合。即使所有的层都运行在同一台物理机器上，它们之间的分离也是有用的。但系统的不同物理架构所处的位置也有所不同。

对于大多数IS应用程序，决定就是是否在一台客户端、桌面机器，服务器上运行处理过程。

最简单的情况就是在服务器运行所有的一切。通过运用使用web浏览器的HTML前端是实现此方案的一个好方法。在服务器上运行一切的最大的好处就是所有东西都是容易更新和修正的，因为它们在都处在有限的地点。你不必要担心在多个桌面机上布署，并使它们与服务器同步。你不必要担心与其它桌面软件的兼容性。

对于赞同在客户端运行逻辑的一般争论就是响应速度或断开连接操作。在服务器上运行的任何逻辑需要服务器对用户的响应做出一次往返。如果用户希望立即看到结果，那么往返就成为了障碍。它也需要一个网络连接来进行操作。

数据源几乎始终只在服务器上运行。例外就是你可能希望将服务器功能复制到一台合适的强大的客户机上。通常出现在你希望进行脱机操作的情况下。在这种情况下，对于脱机客户端上修改的数据需要与服务器进行同步。

对于在何处运行显示的决定很大程度上依赖于你想要的用户界面。运行富客户端多数意味着在客户端运行显示。运行web界面多数意味着在服务器上运行。例外就是在桌面运行web服务器的客户端软件的运程操作（例如，Unix世界中的X服务器），但这种情况很少见。

如果，你正在创建一个B2C系统，那你就没有选择了。任何人都可以连接上你的服务器，并且你不想赶走任何人，因为它们一直在使用TRS-80做他们的在线购物。在这种情况下，你在服务器上做所有的处理，并生成浏览器处理所使用的HTML。使用HTML的局限就是任何一个小的决策都需要从客户端到服务器的一个往返，这将降低响应速度。你需要减少浏览器脚本和可下载的applets，但是这会降低你的浏览器兼容性和其它问题。

人们希望富客户端表现的主要原因是因为一些任务对于用户来说在太复杂了，并希望拥有一个web GUI可以提供的更多的可用的应用程序。然而，人们正在使得web前端更为可用，这减少了对于富客户端的要求。当我写下这篇文章的时候，我更倾向于使用web表现，如果可以的话。

现在只剩下业务逻辑了。你可以在服务器上或客户端上运行所有的业务逻辑或分割它们。在服务器运行所有的逻辑是便于维护的最简单的方式。对于将它转移到客户端的需要或者是响应速度或者是脱机使用。

如果你必须在客户端运行某些逻辑，你可以考虑在那儿运行所有的逻辑－使用这种方式，它们至少都在同一个地方。在客户端运行web服务器对于改善响应速度并没有太大的提高，虽然这是处理脱机操作的一种方式。在这种情况下，你仍然可以在不同的模块中保持业务逻辑和表现的分离，实际上你可以使用Transaction Script或Domain Model达到这个目的。将所有的业务逻辑放到客户端的问题是这种方式需要你做更多的事以进行更新和维护。

在桌面和服务器间分割业务逻辑听起来是最坏的方案，因为使用这种方式，你不知道逻辑片段到底在什么地方。使用这种方式的主要原因是因为你有一些小的业务逻辑需要在客户端运行。这里有一个小技巧是将这个逻辑片段封闭入一个自包含的模块中，这个模块不依赖于系统的其它任何部分。这样，你就可以在客户端或服务器的任何一端运行这相模块。一旦，你选择了你的处理节点，你就应该将所有代码放入一个过程的一个结点中。不要试图将层分离放入不同的过程中，除非你必须这样做。因为，如果这样做会导致性能的下降和当你必须加入例如Remote Facade和Data Transfer Ojbect的复杂性。