学子天地场地申请网站设计问题总结

场地申请代码

由于深大各组织经常要使用校内场地，为了规范各组织使用校内场地，避免使用时间冲突，校团委需要一个系统来管理校内场地的使用。

旧场地申请系统投入使用很多年，之前一直还算稳定，但上一年开始经常出现一些莫名其妙的问题，加上代码实在太乱，所以我就用django重写了。

整个场地申请，功能简单来说就是：各个使用场地的组织在使用场地前先在网上提交使用申请，得到管理员的审批后，该组织可以在管理员拿到使用场地的凭证，方可使用场地，所有申请和审批，都在这个系统上公示。

麻烦的地方是，这个系统需要实现多样而又多变的的申请和审批规则。而且我现在的设计做得很死，都是贴着框架来实现，产生很多问题。

本文将剖析每个细节的设计问题，希望能对学子后人有帮助。篇幅较长。

首先最大的问题是，现在我根据四个场地（学活，会议室，露天场地，展览场地) 分成了四个app来做。但是，由于他们的逻辑本质上是一样的，现在4个app几乎用的是同样的代码（仅仅是部分细节不一样）。当我需要改一个地方的时候，要同时改4份，非常麻烦而且很容易出错。

几乎所有的问题，都是从模型层的错误设计开始的。

那时候团委催得很急，我们都希望能够快速完成这个系统，于是直接仿照旧系统开发。旧系统四个场地 （包括南区运动场，现在没了，但是现在把以前的校园场地拆成露天场地和展览场地），对应四组功能几乎相同的页面，包括

1.提交，修改申请表的页面 

2.分别以表格和列表的方式公示已提交的申请和审批情况的页面

于是仿照旧系统，我很自然地根据申请表设计出模型层。 具体见 场地申请代码  campus_field， meeting_room， student_activity_center 里面的models.py

存储申请内容的数据表就只有一张，完全跟用户填写的表单对应。在此基础上，完成了控制器和视图层。（每个app的views.py放控制器代码）

比较四个app的控制器，可以看到他们的代码几乎是一模一样的！都包括

1. ApplyView 处理提交表单

2. display_table 将申请数据以表格形势展示到页面，实际生成表格结构的代码放在了models.py

3. generate_page 用来生成page对象，不是控制器

4. ListAppView 以列表形式展示已提交的申请

5. ManageView 以列表形势展示自己的申请，在这里页面可以点击链到修改申请的页面

6. get_detail 处理ajax，接受一个对应申请的id，返回对应这个id的申请的基本信息

7. ModifyView 处理修改申请

8. delete 删除申请

9. manage_approve 处理管理员通过审批的请求

既然他们代码都差不多，那他们不同的地方在哪里呢？是什么让他们不能写成同一份，而要拆成四份？

先来看ApplyView，下面是学活的

class ApplyView(View):

    @method_decorator(login_required)
    def get(self, request):
        return render(request, 
                      'student_activity_center/form.html', 
                      {'form': StudentActivityCenterApplicationForm(),
                       'post_url': reverse('student_activity_center:apply')})

    @method_decorator(login_required)
    def post(self, request):
        form = StudentActivityCenterApplicationForm(request.POST,
                                                    request.FILES)
        if not form.is_valid():
            return render(request, 'student_activity_center/form.html',
                    {'form': form,
                     'post_url': reverse('student_activity_center:apply')})
        app = form.save(commit=False)
        app.organization = request.user.organization
        app.save()
        return HttpResponseRedirect(reverse('student_activity_center:manage'))

它跟其他场地不一样的有

1. form 使用的是StudentActivityCenterApplicationForm

2. template文件不同

3. 由于四个场地的申请页面使用的是同一个template文件，所以要传一个post_url 到 template 表单的action字段来告诉表单给哪个场地的控制器提交请求

4. 提交成功后返回的页面url

对于这些不同，我首先想到的是将这些不同的地方参数化，可以通过一个工厂函数接受参数然后返回这个class来实现。但是还是有问题，一旦需要修改活增加新功能，那这些参数也需要跟着改变。而且一旦出现不能参数化的差异，这种方法就行不通。

template文件不一样，是因为各个场地的申请表字段不一样。post_url不一样，是因为处理不同场地申请的控制器不一样。提交成功后返回的页面不一样，是因为管理不同场地的申请的管理页面不一样。

其实管理页面完全可以4个合并成1个来做。这样的话，只要控制器使用的form是不区分场地的，