[enhance] CheckEvent controller with new query endpoints

[Soecka]

Add CheckEvent controller with new query endpoints for user and activity check events

• Closes 统计用户活动数据 #30

[TechQuery]

Suggested change

	export class ActivityAgendaCheckInSummary {
	@ViewColumn()
	@IsString()
	activityId: string;
	@ViewColumn()
	@IsString()
	activityName: string;
	@ViewColumn()
	@IsString()
	agendaId: string;
	@ViewColumn()
	@IsString()
	agendaTitle: string;
	@ViewColumn()
	@IsInt()
	@Min(0)
	checkCount: number;
	}
	export class ActivityAgendaCheckInSummary extends ActivityCheckInSummary {
	@ViewColumn()
	@IsString()
	agendaId: string;
	@ViewColumn()
	@IsString()
	agendaTitle: string;
	}

（上同）

[Soecka]

activity 和 agenda 确实是从属关系，已继承，user 不改动

[TechQuery]

activity 和 agenda 确实是从属关系，已继承，user 不改动

但也是和 User 参加活动相关的数据呀。

[Soecka]

不一定有相关相同字段就一定要继承吧？如果新加用户关注讲师或者普通用户功能，还要把讲师和活动信息关联上吗？这时候应该是用户关注和打卡继承某个 userBaseOperation ？

[TechQuery]

不一定有相关相同字段就一定要继承吧？

它们不但有多个相同字段，而且也都是用户跟活动之间的关联数据统计，代码和语义上都有明显的相关性。

如果新加用户关注讲师或者普通用户功能，还要把讲师和活动信息关联上吗？

那肯定就不能了呀，因为你新功能是用户和用户之间的关联数据统计，和活动就没有关系了，语义和字段都不相同。

[Soecka]

所以这里用户打卡不需要强制继承活动打卡统计，他更适合和关注统计一起继承某个 userBaseOperation

[TechQuery]

所以这里用户打卡不需要强制继承活动打卡统计，他更适合和关注统计一起继承某个 userBaseOperation

首先，我们现在系统中还完全没有“关注”这个功能。

其次，如果以后真有相关功能，软件工程中还有个原则是 —— 不要过早优化。我们现在的优化只针对当前情况，后面如果真有更重复的功数据结构可以继续向上抽基类。

[Soecka]

我关注的点在于，不能因为有相同字段而给两者加上继承关系，“相同字段”这个集合远大于“继承关系”这个集合，我举的例子也是为了说明这两者的差异，没必要为了代码结构好看就“小蝌蚪没有妈先随便给找个妈或者拿表姑表婶当妈”

[TechQuery]

不能因为有相同字段而给两者加上继承关系

“重复代码段”是发现很多“语义继承关系”的直观基础，这是人脑的直觉。

所以不是我“强加了继承”，是我“发现了继承”。