三层架构
在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。微软推荐的分层式结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层（又或称为领域层）、表示层。这也是Java Web中重要的三层架构中的三个层次。区分层次的目的即为了“高内聚低耦合”的思想。
MVC
MVC（模型Model-视图View-控制器Controller）是一种架构模式，可以用它来创建在域对象和UI表示层对象之间的区分。
区别
同样是架构级别的，相同的地方在于他们都有一个表现层，但是他们不同的地方在于其他的两个层。
在三层架构中没有定义Controller的概念。这是最不同的地方。而MVC也没有把业务的逻辑访问看成两个层，这是采用三层架构或MVC搭建程序最主要的区别。
分层的最佳实践
随着网站的用户量的不断提升，系统架构也在不断的调整。有时候，随着业务越来越复杂，有时候三层架构好像不够用了。比如，我们的应用除了要给用户提供页面访问以外，还需要提供一些开放接口，供外部系统调用。这个接口既不属于界面层，也不应该属于业务逻辑层，因为他还可能包含一些和业务逻辑无关的处理，如权限控制、流量控制等。
还有，随着微服务的盛行，我们应用中可能要依赖很多外部接口或第三方平台。这部分代码放下业务逻辑层和数据访问层也都不合适。
所以，渐渐的，在三层架构的基础上，系统架构的分层变得更加复杂了。也正是因为复杂，就非常考验架构设计能力，因为层次划分的不好，很可能会影响后面的开发，给代码维护带来很大的困难。
下图，是阿里巴巴(参考《阿里巴巴Java开发手册》)提倡的应用分层结构：
开放接口层
可直接封装 Service 方法暴露成 RPC 接口；通过 Web 封装成 http 接口；进行网关安全控制、流量控制等。
终端显示层
各个端的模板渲染并执行显示的层。当前主要是 velocity 渲染，JS 渲染，JSP 渲染，移动端展示等。
Web 层
主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等。
Service 层
相对具体的业务逻辑服务层。事务处理层。
Manager 层
通用业务处理层，它有如下特征： 1） 对第三方平台封装的层，预处理返回结果及转化异常信息； 2） 对 Service 层通用能力的下沉，如缓存方案、中间件通用处理； 3） 与 DAO 层交互，对多个 DAO 的组合复用。
DAO 层
数据访问层，与底层 MySQL、Oracle、Hbase 等进行数据交互。
外部接口或第三方平台
包括其它部门 RPC 开放接口，基础平台，其它公司的 HTTP 接口。
异常处理往上抛
DAO层产生的异常类型可能有很多，可能是SQL相关的异常，也可能是数据库连接相关的异常。这一层的处理方式可以简单一点，直接try-catch(Exception)，然后封装成DAOException抛给上一层。这一层一般不需要打印日志，交给Service或者Manager层来打印。
Manager/Service层首先，对于DAO层抛上来的异常一定要捕获的，并且记录日志打印现场。这两层发生的异常可以根据情况决定是继续向上抛还是自己处理掉。如果是自己可以处理的异常，就捕获，打日志，然后通过ErrorCode等方式返回给上一层。如果是自己无法处理或者不知道该如何处理的异常，就直接抛给上一层来处理。
Web 层和外部接口或第三方平台层不可以抛出异常，需要返回友好提示或者友好错误界面，并且记录好日志方便日后排查。
