特老的文章：三层应该怎么划分。不知大家还有用否

可以用这样的思想：
最初的应用是单机，数据和功能都放在一台机器上。随着应用向工作组模式发展中，人们迫切需要
调用彼此的数据，也调用彼此的功能，这样人们就不用重复录入数据，程序员也不须重复写
功能。数据和功能先共享哪一部分？虽然说通过功能就可以把数取出来，数据在功能屏蔽之下，似乎
无须共享出来，但是功能是基于数据的，功能共享出来了，单独放在一台机器上让大家使用，但是这个功能
需要的数据在A，B，C，D...上分布着，到底是谁？所以必须先共享数据。所以才有了C/S模式
一边是数据库，大家都对着这台机器访问数据，一边是大量的客户端，程序都在每台机器上。
随着部门间计算模式的发展，一个系统想存取另一个系统的数据，但是表结构已经很复杂了，
业务逻辑也已经错综复杂了，你已经不可能独自写一段程序存取另一个系统的数据。这时只能合作，
让对方写一个功能，给你开放出来，你一调用就能得到你想要的结果。但是这个功能写好是该放到哪台机器上吗？
肯定不可能放在每个客户端上，又需要单独放在一个机器上，于是C/S/S产生了
这是一个历史，你就明白了三层该放什么东西。
当然也顺便，就是另一些系统不调用的功能也放在了这个公共组件服务器上，来减少数据库连接
虽然有的文章上说这样可以减少更换程序的成本，这点倒不敢苟同，因为从实际开发中，如果客户端是GUI的，
你的很多改动会和GUI改变有关，你还得更新。如果你客户端是WEB，你还必须是三层，因为你客户端什么都没有

至于划分数据层，业务逻辑层只是为了引导你面向对象思考。说是为了更容易的修改，而不影响另一层，这个也是
比较困难，因为往往客户要求多显示一些东西或少显示一些东西，可以这样查，可以那样查，所以
往往数据层的SQL语句老变化，而且大多不能在原SQL上改，因为参数，字段或许都不一样，你改了，客户段的取数就很容易出错，
你也不敢保证它会在什么功能中被公用到，所以往往是又增加一个新SQL，和原SQL看起来90%一样，但又不完全一样。
客户端界面也老变，有时业务校验规则也不一样，业务处理方式也不一样，所以每层都需要改变

往往一个数据对象由两三张关系数据表组成，
在数据层表现为数据对象，但是由于业务处理的重点不一样，也为了速度考虑，取最必要的字段，
所以在这个数据对象中有各种各样的SQL，而不是一个SQL，但是每个SQL都是反映了这个数据对象的一个方面
然后写一些函数，专门针对这些数据对象做业务处理，还有一些函数专门负责数据校验，如不可为空，主键重复，类型出错等

在业务逻辑层分出两枝，一枝是业务逻辑规则校验，在其中也调用着数据层的数据校验规则，
另一枝是业务处理，就是调用数据层的各个函数来组合完成一件事，形成一个流程

总结一下，SQL一般都写在数据层，这是很自然的，业务逻辑层就是组合功能。不管数据层的函数
还是业务逻辑层的数据都和业务相关，对于数据层与业务无关的说法，在实际中行不通，因为在模型上
说，我们写在数据层上的那些接口方法应该是单独又分出一层，叫真正的业务逻辑层，而我这里写的业务
逻辑层，模型中叫Facade，就是为了简化客户端调用而做的外壳。但个人认为，模型中单分出一层意义不大，
因为每层都需要修改，少一层就好修改一些。而且纯粹的面向对象系统在世界上也从来没有存在过，如果
存在，那必定是一个理论家的东西，而不能实用，就象在实际中我们在设计关系型数据库时先三范式，后为了简化
编程和提供速度而反三范式。
客户端也不是多个功能放一个PAS文件中。因为客户往往要求功能组合。如A要和B功能放在一个界面，
B和C要拆开，所以客户端也是界面和数据操作和数据显示分开，为了在界面上看到的是多个功能在一起
但实际中却各不混杂，这是个功能模块划分，不是层次划分。如果从界面观点来看，是层次问题，因为界面和功能算两个层次

不要拘泥于理论，也不要放弃理论埋头编程，而是互相借鉴前进，目的就是两个，为了业务处理需要，
为了我们好维护程序。

再看看我开头讲的历史，你会发现，历史就是为了这两个目的而变化