请教一个概念性的问题（三层和设计模式）？
      三层架构是不是一种通用型的程序设计架构模式，不论在什么样的业务需求和逻辑下，都可以使用三层架构来实现和解决问题？
      如果这样的话，23种设计模式的作用和意义又是什么呢，针对具体问题使用更精准的解决方案么？

      我现在的理解是：三层架构是一种通用的、基本的设计模式，可适用于几乎所有的项目中。而Gof 23种设计模式是针对更具体的业务逻辑总结出的优秀的解决方案，并不适合所有的场景。我的理解是否正确呢？
------解决方案--------------------
设计模式是解决问题的方法。
架构是程序的结构。
------解决方案--------------------

引用:

本帖最后由 ptyzhu 于 2013-03-30 13:49:41 编辑
                  三层架构是不是一种通用型的程序设计架构模式，不论在什么样的业务需求和逻辑下，都可以使用三层架构来实现和解决问题？
      如果这样的话，23种设计模式的作用和意义又是什么呢，针对具体问题使用更精准的解决方案么？

      我现在的理解是：三……

三层架构：是面向整个系统的结构。 目的是解决系统中 界面/主域逻辑/数据库逻辑 混杂在一起，难以维护扩展的问题
23种设计模式：是针对特定的场景提供通用的较好的实现方式。
------解决方案--------------------

引用:

本帖最后由 ptyzhu 于 2013-03-30 13:49:41 编辑
                  三层架构是不是一种通用型的程序设计架构模式，不论在什么样的业务需求和逻辑下，都可以使用三层架构来实现和解决问题？

晕死！

所谓三层，是任何“分层”概念中最低级的东西。因为简单的信息系统，就是拖一些（比如说）Label、ListView、DataGrid控件之类的，然后跟数据库绑定在一起。在此基础上，稍微要分点层次出来，别的什么层次都不懂的情况下，最低级地就是把具体的关系数据库隐藏起来，而做一个通用的数据访问接口层。

比如说一个通过移动公司的网络来运作的业务系统，我们就可能让任何数据访问的服务方法（或者说这个方法所属于的命令class）都继承自我们的“根据流量计费的业务class”，这就是多出一个层次来了（这个计费class可能需要写上几千行）。我们都不谈这类实实在在的分层，就谈虚的，最低级地就是把原先的两层变为三层，才可能再加上更多更具体的吃层次。

因此三层，是天底下最低级的分层，就好像一个幼儿刚刚学会了写字一样，是启蒙。