MVC分离原则在Django后端中的体现

在本学期的系统分析与设计课程中，我们接触到了MVC这一模式。在没有进行大作业的实践之前，我对MVC的理解并不是那么深刻。在大作业中，通过对Django框架的使用，我对MVC的理解逐渐加深。现在写下这篇博客对我的个人理解做下备忘，希望将来能拿来做个参考。

什么是MVC

首先先总结一下课程中学到的MVC的知识。MVC是Model-View-Controller的缩写。MVC把应用分为模型、视图、控制器三层，这些层之间以一种松耦合的方式连接在一起，模型负责业务对象与数据库的映射，视图负责与用户的交互(页面)，控制器接受用户的输入调用模型和视图完成用户的请求。MVC的原则之一是分离的原则，即Model Objects与View Objects不能耦合在一起，也不能直接进行连接（页面不应该直接对数据库进行操作，数据库操作的结果也不应该直接返回到页面）。业务逻辑不应该放入UI Object的方法中。

这种分离的目的有以下几点： 

1. 允许模型与用户界面的独立开发。

2. 最小化界面因需求变化而造成的对领域层的影响。

3. 使模型层在不同用户交互框架之间的迁移变得容易。

Django后端的工作机理简要以及MVC分离原则在其中的体现

我们组大作业的backend文件夹中包含了下面几个文件：

其中models.py中定义的各种类代表数据模型（Model），和数据库引擎交互，执行数据库数据的存取操作；urls.py中定义的各种url访问入口和views.py中定义的各种处理函数代表控制器（Controller），其中的urls.py可以根据用户输入的url请求，调用views.py中相应的函数与数据模型和视图交互，响应用户的请求。

下面是views.py中的一个视图函数：

这个函数接收前端发送过来的HttpRequest后在数据库中搜索电影院并把搜索结果包装进HttpResponse返回给前端。这样就避免了前端直接向数据库发送请求对数据库进行操作。这个函数的url则包含在urls.py文件中，前端只能通过向该url发送请求进行数据库的检索。这样就可以把前端界面和数据库分割开来，即便前端发生变化也不需要修改数据模型。另一方面，前端只要发送相同格式的HttpRequest给同样的url即可完成同样的逻辑功能。这样前后端就可以进行相互独立的开发工作。

下面是models.py中的一个类，该类对应了电影院的数据模型：

可以看到，models.py中只包含了数据模型且不包含任何控制器、界面的代码。就算views.py发生改变也不需要改变models.py。同理，前端的改变也不会影响到models.py。这就实现了数据模型的可重用性。

补充内容：Django中的命令模式（Command Pattern）

在软件系统中，行为请求者与行为实现者通常呈现一种紧耦合。但在很多场合下，这种紧耦合是不合适的。将一组行为抽象为对象，实现二者之间的松耦合，这就是命令模式（Command Pattern）。
命令模式有以下特点：
1.命令模式的本质是对命令进行封装，将发出命令的责任和执行命令的责任分割开。
2.每一个命令都是一个操作：请求的一方发出请求，要求执行一个操作；接收的一方收到请求，并执行操作。
3.命令模式允许请求的一方和接收的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否被执行、何时被执行，以及是怎么被执行的。
4.命令模式使请求本身成为一个对象，这个对象和其他对象一样可以被存储和传递。
5.命令模式引入了抽象命令接口，且发送者针对抽象命令接口编程，只有实现了抽象命令接口的具体命令才能与接收者相关联。
在Django中，把get和post这些请求的行为抽象成一个HttpRequest类，可以通过request实例的method获取行为的类型：比如上图中就通过request.method=='POST'这一语句判断请求是否有POST的行为。Django把返回的行为抽象成HttpResponse类，通过调用HttpResponse的方法向前端返回数据。此外，对于Json、File等数据，Django也分别抽象了相应的类来处理，在此不一一详述。可以看到，命令模式对Django中MVC的实现起着重要的作用。通过将请求和返回抽象化，使得前端的交互能与后端的处理分开，从而达到View和Controller之间的解耦。