现在开始进入正题，先简略地描述一下整个系统的功能，主要为下面我的一些设计作一下铺垫。
签到系统分前台显示与后台管理控制二大部分。
前台根据硬件设备读到的信息，显示当前签到者的信息，并分类别更新本机已签到的人数及已签到总人数。与此同时，显示当前的网络连接状态等等。这个是基本功能，附属功能后面讲。
后台管理着签到系统的数据库，对数据表的一些基本增、删、改、查询操作是必不可少的，打印功能当然也是逃不了的。最重要一块当然就是对于签到过程的管理控制，何时开始、何时停止等等，然后就是半实时的显示当前签到人数，显示当前所有前台的工作状况及各硬件设备的状态。
至此为止，功能都还比较中规中矩。但基于此系统的应用场合，必须要考虑许许多多的情况，即便这些情况出现的机率非常低。
首先就是网络不正常的状况，如果现场网络不正常整个系统不会瘫痪，网络恢复了正常，对签到过程的继续进行及签到统计也不会产生干扰。
再来考虑前台客户端，RFID硬件设备产生的故障，如果无法在短时内排除也是比较致命的，所以给一些客户端又配置了手持式设备以防万一。当然网络如果不正常，那签到控制指令也是无法接受到的，所以在前台客户端又得加些签到控制的动作。既然签到嘛，当然得有签到的凭证（就是含有RFID芯片的证件），但有时与会者由于各种原因可能无法提供，或是证件损坏无法自动签到了，那得有手动签到功能来补充。
考虑完前台再考虑后台，上面提到的手动签到功能，由于各种原因（比如要核对人员呀等等）其实一般是在后台进行的，有手动签到的，当然就得有手动取消的。前面考虑了网络出现异常的情况，我们也不能排除电脑本身出现异常的情况，双机热备份之类的措施也是需要提到功能表里的。
一直到这里，功能都是很标准的，也符合我们对于一个完善的系统的概念。但签到系统不是一个孤立的系统，它是承上启下的。它的基础数据从哪来，它的与会人员的信息是从人事数据库来的；它的结果到哪去，签到的统计结果是会议合法性的依据（如果有选举那就是选票发放的依据，当然选举出于严谨考虑是有一个人工清点人数的过程的）。
跟我们在公司考勤不一样，公司那点人基本是固定的。但这参加某次会议的人，跟前一次相比可能是千差万别的。所有这些人，不管是这次参加会议的，还是上次参加会议的，或是二次都参加的，当然肯定是某个大集合里的子集，但那个大集合我们是不可能接触到的，即使是客户本身管签到这一块的人也是接触不到的。
还是跟考勤相比，每天上下班打卡的结果到月终是会有用的。但这会议签到的结果，除了当时报个人数，以及事后打几张缺席名单外基本就没什么大的作用了，至少我接触下来是这么回事。
最终的现实与脑海里那个理想的会议签到系统是不太一样的，这完全是一个一捶子买卖。这样为了减少数据录入的工作量，系统新增了一个数据批量导入的功能。出于系统简单性的考虑，我们暂且认为二次导入的数据之间是没有关联的，在数据库里只存放当前签到会议的数据。为了备查签到数据的考虑，系统又新增 了数据的备份恢复功能（让客户自己去用数据库的备份恢复功能当然不太友好）。
基于一捶子买卖的设计当然不是一个很好的设计，如果不是此种类型的会议适用性将大打折扣。会议签到数据的归档是一个应该考虑的功能，但最终时间的压力及客户也无此种要求没有加入进去。或许如果以后此系统应用于别的场合再行添加了。