请问在讨论组织结构时，如何分析非三层的分层模式？

本文共计1847个文字，预计阅读时间需要8分钟。

讨论完语言又讨论培训，讨论完培训再讨论分层，这些话题似乎永远讨论不完。讨论本身是有益的，但如果讨论的主题本身存在问题，可能就会导致副作用，使得益处不如预期大。三层讨论

讨论完了语言又讨论培训，讨论完了培训又讨论分层，这些话题似乎永远都讨论不完。讨论总是有益的，但是如果讨论的命题本身就有问题的话，可能副作用就比益处来的更大了。

三层 ＝ 表现层＋业务逻辑层＋数据访问层 ？

是不是所有系统一定要分成三层，是不是所有三层的系统都一定是这三层，如果我写一个不需要数据存储的应用呢，如果我写一个没有界面的程序（库）呢？

为什么一提到三层就是这三层？因为所有的讨论都是基于“中小型b/s或c/s应用系统"，因为这样的系统现在最常见，也是做的最多的。但是我们不能仅仅将眼光局限在这个领域里，而是应该放的更长远，分层是一个普遍使用的概念，不能仅仅局限于“三”层，也不能仅仅局限于"UI+BL+DAL"。三层只是分层的一个特例，UI+BL+DAL的组合也只是三层系统的一个特例，理解了特例不代表理解了分层；而理解了分层自然就能理解这个特例了。因此请不要在讨论三层了，直接讨论分层吧，这样可以少一些误解，少一些争论。例如，那些说三层（UI+BL+DAL)不好的人，不会因此而否定分层，他仍然可以分两层或者一层，而不是拒绝分层；讨论也会仅仅限于此三层是否好用，是应该改变之中的某一层还是改变层次的数目，什么时候应该分三层，什么时候应该分两层。

再来说说分层的优缺点，任何东西都不是完美的，它只能解决某些特定的问题。解决不了所有的问题不是它的错，使用它来解决它不善于解决的问题绝对是你的错。

我喜欢分层的原因是：分层可以将底层操作包装，使你在任何一层工作时，可以只考虑下面的一层，而无需考虑更下面的所有层的细节，甚至是一共有多少层。