关于三层架构与MVC的一些理解

刚毕业的时候，参与了一个上位机的系统开发。上位机所使用的是.net Windows Form技术。

当时，和一个北理的姑娘在一个项目组里。因为她来公司时间比较长，而且经验比较丰富，所以，上位机的架构由她来做。

在项目开始，她设计了整个项目的脚手架。这个脚手架大概是这样设计的：

1. 采用“三层架构”搭建整个系统

2. 该“三层架构”分为：UI层，业务逻辑层，实体层

• UI层包含了所有的Windows窗口、控件
• 业务逻辑层包含了所有的业务逻辑、数据库访问等
• 实体层包含了所有的业务实体，其实类似与Java Bean

3. 每一个业务模块都对应的有一个.net动态链接库项目，每一个业务模块按照上述第二点的“三层架构”进行分层

这个项目终究是“上线”了。后来想来，这个项目架构存在一些问题点。

1. 因为模块的业务量很小，但是模块很多，每一个模块对应一个DLL项目，而模块之前存在不同程度的依赖，例如：实体与实体之间的依赖，所以整个模块的依赖关系非常混乱。

2. 对“三层架构”的理解不到位。按理应当先分成主要的三层，UI层、业务逻辑层、数据访问层，数据访问层是比较稳定的，产生了非常多的、混乱的代码

3. UI层没有组件化，很多Form都是通过拖拉拽.net的控件拼凑而来，造成了很多的UI控件重复，无法复用。。

4. UI层的代码与业务逻辑代码紧紧联系在一起，一个复杂的Form文件甚至超过了2000行的代码

以这个我亲身经历的案例作为引子，来谈一谈我对三层架构、以及MVC的理解。

三层架构

现在可能听到“三层架构”的机会少了。在我毕业那会，三层架构是非常流行的。三层架构主要分为：界面层、业务逻辑层、数据访问层。这种分层架构是一种基本的模型，我们很多时候会分出来更多的层。例如：实体层、服务层。这里，我们来分别谈谈每一层的职责。

界面层：界面层就是我们经常说的UI，可以是Form、可以是Control、可以是HTML/CSS/JS。这一层主要是用来提供给客户的界面接口的。

业务逻辑层：业务逻辑层包含了所有对系统业务功能的操作。例如：生成一个订单、提交订单到生产部门等等。

数据访问层：对数据库的访问。

相信大家都很了解这几个层的职责，但它们之间是怎么交互的呢？

1. UI层与业务逻辑层的交互往往都是以事件驱动来调用业务逻辑层，因为业务逻辑层返回给UI层的往往是一些业务实体，所以，UI层同时依赖与业务实体

2. 业务逻辑层依赖于数据访问层。业务逻辑层会组装各类数据访问操作，从而给UI层提供服务

3. 数据访问层直接操作数据库，执行各种SQL操作。

这三层都会依赖于业务实体，所以，往往我们都会在项目里添加实体这一层。

接下来，我们再看看MVC

MVC

MVC大家都很熟悉。分别是Model层、View层、Controller层。

1. Model层一般会分为Service层、DAO层、Entity层

2. View层主要为视图，就是用来提供给用户操作界面的接口

3. Controller层是与三层架构的一个重要区别，它像夹心饼干中间的那一层。Controller层把Model和View层连接到一起。

它们之间的交互关系如下：

1. View调用Controller中的接口，进行数据操作，Controller执行完后更新View。

2. Controller依赖与于Model层，接受到用户的操作后，Controller根据客户的不同请求执行不同的服务。

3. Model层，Model层包含了主要业务逻辑、数据存取等操作。之前的Structs，View层会依赖Model中的实体，直接将实体按照固定的模式展现到视图。

最后，我们回过头来看看三层架构与MVC。

在网上看别人的帖子，很多人说三层架构与MVC没有任何关系。我觉得这个说法有点不太妥当。其实，它们的本质都是分层。只是对层次的划分有一些区别。

1. 因为三层架构中没有Controller层，所以UI层是比较胖的。往往在UI层中包含了大量的业务逻辑代码

2. 三层架构中业务逻辑层和事情数据访问层其实就是MVC中的Model层。对应Service和DAO

可以说，MVC是三层架构的升级版，现在的很多架构其实就是分出来更多的层，分层的目的也比较明确，就是要解耦和。每一层单一职责，某一层做一件事情。其实，这些思想都是相同的，如果我们再细分到面向对象设计。我们也提倡SRP，其实与我们的架构要解决的问题是类似的。

另外，有不少人认为三层架构是一种架构、而MVC是一种设计模式。我觉得这是在咬文嚼字了。那我叫做“三层模型”好吗？他们就是一类东西，都是在分层，都在解耦。

这样一想，我觉得清晰多了。