支持文件分类相关 API

[AsakuraMizu]

close #57

[AsakuraMizu]

• 教师端的 getFileListByCategory 还没有做，API 只找到一个 form post 的接口，看起来比较麻烦就先没弄
• getAllContents 要加上文件分类的获取吗？

[Harry-Chen]

• getAllContents 要加上文件分类的获取吗？

我在思考要不要直接把 Category 的文本写进 IFile 的类型里面（同时也保留 ID 备用），这样的话似乎加不加都可以

[AsakuraMizu]

我在思考要不要直接把 Category 的文本写进 IFile 的类型里面（同时也保留 ID 备用）

但是这样会产生一个微妙的问题：对于原先的获取全部文件的接口，lib自动地“顺便”获取一下分类列表是可以接受的；但是现在有了按分类获取文件的接口，在这个接口里加入这个逻辑显然是不可接受的。
或者就不要这个按分类获取的接口了

[Harry-Chen]

我在思考要不要直接把 Category 的文本写进 IFile 的类型里面（同时也保留 ID 备用）

但是这样会产生一个微妙的问题：对于原先的获取全部文件的接口，lib自动地“顺便”获取一下分类列表是可以接受的；但是现在有了按分类获取文件的接口，在这个接口里加入这个逻辑显然是不可接受的。 或者就不要这个按分类获取的接口了

“这个接口”是指全部还是按分类？我感觉在全部信息里面加入没什么太大问题，毕竟不是在设计数据库，不需要太严格的消除冗余

[AsakuraMizu]

我在思考要不要直接把 Category 的文本写进 IFile 的类型里面（同时也保留 ID 备用）

但是这样会产生一个微妙的问题：对于原先的获取全部文件的接口，lib自动地“顺便”获取一下分类列表是可以接受的；但是现在有了按分类获取文件的接口，在这个接口里加入这个逻辑显然是不可接受的。 或者就不要这个按分类获取的接口了

“这个接口”是指全部还是按分类？我感觉在全部信息里面加入没什么太大问题，毕竟不是在设计数据库，不需要太严格的消除冗余

在 getFileList 里加没什么问题，但是要改 IFile 的话，getFileListByCategory 也得返回分类信息，用户调用 getFileListByCategory 的时候肯定是已经有了分类列表再依次做每个分类的查询，如果这里边再获取分类信息的话就要多调用好多次 getFileCategoryList

那或者还有个办法是给 getFileListByCategory 加个可选参数让用户传已经获取到的分类列表，用户没传的话就自己获取；但是这样还是避免不了如果用户没传的话每次调用都要拉一遍列表；那不然就加 cache，但是加 cache 就有点儿超出这个 lib 应该管的东西了

本来我是想这么说的，刚想明白可以让分类信息是 optional，getFileListByCategory 就不自动映射分类了

[Harry-Chen]

LGTM