何时分层

虽然我们可以通过显示、业务和数据源的单独的例子辨别出它们的职责，每个例子都有它们自己的关于它们如何分离的问题。如果每一个职责都相当的复杂，那将它们分离到他们自己单独的模块中将变得很意义。一个有复杂逻辑的应用程序对于表现、业务和数据源应该有它的单独的包结构。事实上，它将有更进一步的中间层。但简单一点的系统可能不会有这些包。如果你所做的所有工作就是查看简单的数据项，那么将所有的逻辑都放入一系列服务器页面中将会更合理，特别是你有一个使得完成这些服务器页面变得简单的工具。

分享这些职责的方法不是我能轻易定义的。我不能说如果你的业务逻辑的复杂度大于7.4，你就应该将它与表现分离。我的实践是几乎始终将表现与业务和数据源分离。我违反这一原则的唯一情况是业务的数据源复杂度几乎为零，并且我有将所有层捆绑在一起的工具。对于这种情况的一个经典的例子是很多在例如VB或PB环境中开发的C/S系统。它们使得在SQL数据库上创建富客户端界面变得很容易。如果提供与数据库结构非常接近的表现，并且几乎没有任何校验和计算，我就会直接使用它。但是，只要校验和计算开始变得复杂，我就会试图将它分离出来，封装到单独的对象中。

我更倾向于将业务与数据源分离。对于很多简单的应用程序，它们两个看起来会十分相似，所以，我倾向于将它们放在一起。但，一旦我组织业务逻辑的方式开始与定义数据源的方式显得不同的时候，我就会想把它们放入不同的模块中。

当我描述一个分层应用程序时，我喜欢作用一个UML包图显示包和它们之间的依赖关系。我在这里没有展示一个，因为实际的依赖关系在很大程度上依赖于你实际使用的模式。一个绝对的原则就是没有任何东西依赖于表现。业务或数据源层中的模块绝对不能调用表现中任何东西。这有时在显示需要根据业务中的变动进行刷新时就会产生问题，在这时你会需要使用观察者模式以防止对于显示的依赖。