微信抢票总结博客

由于时间安排上的问题，微信抢票的工程紧赶慢赶才最终勉强赶在ddl之前完成。“一定要安排好时间，越早动手越好”，这大概会是我从中得到的最有意义的教训吧。

下面说一些我对这一工程的一些理解吧。这些内容在文档中都有，在这里还是再重复一遍。

本项目是在Django 1.9.x封装的基础上进行的二次开发，开发内容主要集中在作为Controller的APIView与WeChatView两部分，分别对应API接口与微信接口。

1、APIView

API接口主要用于后台管理（活动和票的管理）、用户手机端页面与后端的交互等。而对应的APIView类，是所有前后端接口的基类。在APIView的子类中，具体的GET或POST接口只需要返回data即可，其他包括异常（Exception）的捕获、JSON的序列化等，都已经做好了封装。

因此，基于以上框架的二次开发，只需针对每一个接口创建一个继承自APIView的类，根据具体的功能实现其GET和/或POST方法，并且利用基类中已经实现的as_view()方法直接与给定的前后端接口的url绑定即可。

2、WeChatView

微信接口主要负责处理微信消息，实现微信交互业务逻辑。具体来说，微信消息由WeChatView处理，这其中定义了若干WeChatHandler，通过依次调用它们的check方法，传入的消息将被交给第一个返回true的WeChatHandler的handle方法进行处理。

基于这样的框架，二次开发便需要增加、实现具体的WeChatHandler的check和handle方法，以实现绑定/解绑学号，查看活动详情，抢票/退票等功能。在实现的过程中中，为了方便，还在封装函数模块wrapper中添加了一些功能性的函数。

3、重点与难点说明

APIView部分并不太过困难的地方，相对而言值得一提的有：管理员用户利用了Django本身的权限管理模块auth；上传图片的保存采用了最基本的静态存储方式，没有使用数据库。

WeChatView部分同样没有什么太过困难的地方，需要说明的有：在绑定学号验证身份时使用的id.tsinghua.edu.cn的接口目前对校外封闭，项目中暂时不做验证全部通过；业务逻辑涉及许多限制条件的检查，比如抢票时的抢票时间、余票量等，容易遗漏而出现问题；业务逻辑的对应的数据库操作也涉及多个数据项，同样容易遗漏而出现问题。

上面这些内容就是我对工程在技术上的理解，接下来我来谈谈自己的收获。这是我第一次独立完成，事实上也是第一次完成，以部署到服务器为终点的一个项目。所以，我的第一点收获就是增进了对服务器的了解，积累了配置服务器并将项目部署到服务器端的最基本的经验。另一方面，这个项目也是我第一次进行微信公众平台的相关开发，在完成项目的过程中，我对微信服务器也有了初步的了解，这算是我的第二点收获。此外，我在完成这个项目的过程中第一次使用了“花生壳”之类的内网穿透工具；项目架构中体现出的优秀设计思想也让我有切实的感受。总之，这次项目中有很多部分都是全新的，接触这些事物，让自己从不熟悉变得熟悉，应该算是我最主要的收获了。