三层架构、MVC、前后分离的一些知识
三层架构、MVC、前后分离的一些知识
- 三层架构模型
- MVC模式
- 三层架构与 MVC 架构区别
- 前后端分离开发时的变化
- 一个前后端分离项目的分层
-
- 前端
-
- MVVM
- 后端
-
- Service层
- Model层
- Mapper映射
- BLL业务逻辑层
- DAL数据访问层
三层架构模型
三层架构为：UI（表现层）、BLL（业务逻辑层）、DAL（数据访问层），此外还有一个必不可少的Entity（实体层）
其中
Entity实体层，与数据库相对应，主要存放数据库字段。
DAL数据访问层，主要是存放对数据类的访问，即对数据库的添加、删除、修改、更新等基本操作。
BLL业务逻辑层，是UI和DAL之间的桥梁，主要负责实现业务逻辑。业务逻辑具体包含：验证、计算、业务规则等等。
UI表现层即用户界面。用于接收用户输入的数据和显示处理后用户需要的数据。
UI发用用户请求到BLL，BLL传递请求到DAL，DAL反馈回数据，并通过BLL传递给UI。
Entity在这三层架构中的作用：
- 实现面向对象思想中的"封装"
- 贯穿于三层之间，来连接三层
- 每一层（UI—>BLL—>DAL）之间的数据传递（单向）是靠变量或实体作为参数来传递的，这样就构造了三层之间的联系，完成了功能的实现。
MVC模式
MVC架构是一种开发模式，与三层架构不是一个类型的概念。如果将MVC模式和三层架构关联起来看的话，可以理解为MVC是三层架构的UI层。MVC 模式把三层架构中的 UI 层再度进行了分化，分成了控制器、视图、模型三个部分。
- 模型（Model）：需要显示给页面的数据模型。
- 视图（View）：页面本身。
- 控制器（Controller）：就是完成页面逻辑，即获取页面数据和显示的页面视图，并进行页面渲染为最终展示效果。
三层架构与 MVC 架构区别
- 三层架构是基于业务逻辑来划分的，而 MVC 架构是基于页面来划分的
- 三层架构是采用分层的设计思想，而 MVC 架构不是分层而是按照职责划分的
- 三层架构主要用于软件体系架构，MVC 架构主要用于表现层
前后端分离开发时的变化
当项目前后端分离时，从MVC的角度理解，MVC中的V（View）和C（Controller）便不存在了。原先一个项目便分成了两个项目，后端项目通过webapi提供数据服务，前端项目通过后端提供的服务获取数据并进行页面渲染。
分离出来后，前端通常也会有自己的开发模式，常用MVVM模式。即Model-View-ViewModel。
后端中，原MVC中的Model层设计思想还是可以用，然后在此只是增加一个Service层，给前端项目通过提供webapi提供数据服务。
一个前后端分离项目的分层
前端
MVVM
以下是WPF项目关于MVVM的一些思想，web前端项目后面学习补充。
MVVM 模式中有三个核心组件：模型、视图和视图模型。 每个组件的用途不同。
在MVVM的设计思想下，ViewModel将View与Model隔离，并允许Model独立于试图进行演变。
使用 MVVM 模式的好处如下：
- 如果现有模型实现封装了现有业务逻辑，则更改它可能很困难或有风险。 在此场景中，视图模型充当模型类的适配器，并阻止你对模型代码进行重大更改。
- 开发人员可以在不使用视图的情况下为视图模型和模型创建单元测试。 视图模型的单元测试可以执行与视图使用的完全相同的功能。
- 无需接触视图模型和模型代码即可重新设计应用 UI，前提是视图完全在 XAML 或 C# 中实现。 因此，新版本的视图应与现有视图模型一起使用。
- 在开发过程中，设计人员和开发人员可以独立和并发地处理其组件。 设计人员可以专注于视图，而开发人员可以处理视图模型和模型组件。
后端
Service层
后端给前端提供具体的WebApi服务，主要有以下的几个作用：
- 将业务逻辑层进行封装，对外提供业务服务调用。
- 通过外观模式，屏蔽业务逻辑内部方法。
- 降低业务逻辑层与UI层的依赖，业务逻辑接口或实现的变化不会影像UI层。
- 降低UI层调用的请求次数及数据往返。
Model层
需要显示给页面的数据模型，即常用的DTO层。
在实际的业务场景下，后端实现或存储的数据远比用户需要的数据要庞大和复杂，所以前端需要的数据相对来说要么是组合的，要么是抽取的，不是完整的，因为在设计数据存储格式上都会有一些额外的设计和考虑，便产生了DTO层。
DTO(数据传输对象层)，该层负责屏蔽后端的实体层，将UI层需要的数据进行重新的定义和封装。
前端的UI层，只是知道DTO的存在，同时前端需要的数据都在一个DTO中，这样，每次调用服务层的时候，只需要调用一次就可以完成所有的业务逻辑操作，而不是原来的直接调用业务逻辑层那样的，需要调用多次，对于分布式场景下，减少服务调用的次数，尤其重要。
在实际开发中，常会将DTO与Entity做一一对应映射，需要关联多个表视图时，会自己另外创建Model来定义新的数据模型。
Mapper映射
将DTO和Entity之间相互映射，一方更改，另一方同步。
DTO与前端打交道，前端也只知道DTO，不知道Entity和数据库；
Entity和数据库打交道，数据库只知道Entity，不知道DTO和前端。
所以增加DTO和Entity之间的映射，否则前端和DTO数据变化时，无法通知到数据库，数据库数据变更时，无法通知到前端。