离职后的第一次面试，对方 CTO 上来的第一个问题就把我问住了。即标题所示，什么是三层架构，完全没听过，真乃奇耻大辱！特地搜索了一下资料，发现这个其实是没有标准答案的， 因为这两个东东本身都是基于架构层次的东西，可以从不同的方向理解，用起来的话也是大致遵从它们各自的标准，因而没有教科书式的标准答案。鉴于此，我根据自己的理解，整理出 内容如下。
概念上的比较
MVC
网上随处一搜就说 MVC 是一种设计模式，在我无意间搜索到知乎上的一个问题为什么23种设计模式里面没有MVC?,才发现这种说法是不严谨的。
GoF (Gang of Four，四人组， 《Design Patterns: Elements of Reusable Object-Oriented Software》/《设计模式》一书的作者：Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides)并没有把MVC提及为一种设计模式，而是把它当做“一组用于构建用户界面的类集合”。在他们看来，它其实是其它三个经典的设计模式的演变：观察者模式(Observer)(Pub/Sub), 策略模式(Strategy)和组合模式(Composite)。根据MVC在框架中的实现不同可能还会用到工厂模式(Factory)和装饰器(Decorator)模式。我在另一本免费的书“JavaScript Design Patterns For Beginners”中讲述了这些模式，如果你有兴趣可以阅读更多信息
正如我们所讨论的，models表示应用的数据，而views处理屏幕上展现给用户的内容。为此，MVC在核心通讯上基于推送/订阅模型(惊讶的是 在很多关于MVC的文章中并没有提及到)。当一个model变化时它对应用其它模块发出更新通知(“publishes”)，订阅者 (subscriber)——通常是一个Controller，然后更新对应的view。观察者——这种自然的观察关系促进了多个view关联到同一个 model。
对于感兴趣的开发人员想更多的了解解耦性的MVC(根据不同的实现)，这种模式的目标之一就是在一个主题和它的观察者之间建立一对多的关系。当这个 主题改变的时候，它的观察者也会得到更新。Views和controllers的关系稍微有点不同。Controllers帮助views对不同用户的输 入做不同的响应，是一个非常好的策略模式列子。
由以上内容我们可知，MVC 更多的是架构层次的，比设计模式上要更高级一层，是观察者模式、策略模式、组合模式的进一步的应用。
MVC 的具体内容
M（Model）：模型是用来处理具体的逻辑的关系，在 rails 中，它肩负着连接数据库，即对持久化数据处理的任务，并与数据库中的有表一一对应的关系； C（Controller）：控制器是用来调用上一步中模型的方法，它更像是一个步骤大纲，第一步做什么，第二步做什么…但具体做的内容是在 Model 中。而控制器也有着连接视图层与代码层的桥梁作用。 V（View）：视图层即是与用户进行交互的界面。
三层架构
百度百科中的定义：
通常意义上的三层架构就是将整个业务应用划分为：界面层（User Interface layer）、业务逻辑层（Business Logic Layer）、数据访问层（Data access layer）。区分层次的目的即为了“高内聚低耦合”的思想。在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。微软推荐的分层式结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层（又或称为领域层）、表示层。
三层架构具体内容
摘取百度百科
数据访问层：主要是对非原始数据（数据库或者文本文件等存放数据的形式）的操作层，而不是指原始数据，也就是说，是对数据库的操作，而不是数据，具体为业务逻辑层或表示层提供数据服务．
业务逻辑层：主要是针对具体的问题的操作，也可以理解成对数据层的操作，对数据业务逻辑处理，如果说数据层是积木，那逻辑层就是对这些积木的搭建。
界面层：主要表示WEB方式，也可以表示成WINFORM方式，WEB方式也可以表现成：aspx，如果逻辑层相当强大和完善，无论表现层如何定义和更改，逻辑层都能完善地提供服务。
总结
以上可见，三层架构更多是抛开代码基于业务来谈的，而 MVC 是更多的是基于代码逻辑代码层次上来谈的。 所以，直观上，MVC 让代码的层次更清楚，而三层架构让业务的层次更清楚。从这个角度来讲，他们是毫无关系的两种架构层次的分法，具体应用中很容易形成你中有我，我中有你的形式。但从另一方面来讲，它们的核心目的是一致的，都是为了让代码便于理解，项目便于管理。
而如果非要找他们逻辑上的关系，则大致如下图：
