打卡钟

本文参考自狄泰软件学院――《12月门徒计划》 核心 ：将现实世界直接映射到软件世界 意图 ：便于沟通和理解，降低复杂性，增加维护性 要点 ：使用现实世界中的概念 案例：任务与内存访问 TaskA可以访问Memory1内存和Memory2内存； TaskB可以访问Memory2内存和Memory3内存； TaskC不能访问这3片内存。 问题：如何使用现实世界中的概念引入到该案例中？ 我们可以使用公司中打卡的机制引入到该案例中。 1、每个员工都有一张工牌，相当于案例中的Task 2、工牌可以用于打卡，也可以用于开门（并不是每一个员工都有权限进入所有部门，需要区分开来）。也就是每个Task访问的内存不相同。 3、现实中每个工牌都有一个唯一的ID。 4、当访问具体内存时，工牌的ID号传到打卡机中，打卡机也存在一个ID号；然后打卡机将工牌ID号和打卡机的ID号一起上传到远端的控制中心。 5、控制中心中的数据库对工牌ID和打卡机ID进行匹配。查询工牌ID是否有权限打开这个门，然后再返回到对应门。开锁或报警。 由此我们可以设计出相应的架构设计图 在这个示例当中，我们是完全使用了实现世界中的例子，因为这样进行开发软件会使别人容易理解该软件的架构以及设计原理。如果我们使用一些高深的专业名词，则会业余人员不理解。 文章来源: 以人为本的设计原则

问题 　　前同事编写的对中控考勤机数据集成项目当中，打卡数据不能实时进行上传到平台当中，一直靠定时全量上传来同步数据。 　　阅读代码后，发现代码中有实时上传数据的逻辑，但是运行一段时间后，中控zkemkeeper SDK中的事件失效，导致员工打卡数据没有实时上传。 原因 　　 查看中控SDK Demo中的示例代码，发现实现逻辑是一样的。唯一不同的是demo使用的是winform项目编写，打卡机同步项目是用windows服务项目编写的。 　　发现中控考勤机 zkemkeeper SDK是COM组件封装，这和winform窗体控件是一样的，基于消息循环机制。例如：winfrom项目当中 main函数都这样启动主窗体 Application.Run(new form1()); 　　 也就是说当你实现sdk类的时候，不在线程中进行消息循环，就有可能导致事件失效。 解决方式 　　 定位了可能导致问题的原因，我对考勤机数据获取类进行如下改动： 　　1. 为了简单将连接连接打卡机设备和触发打卡的方法直接移动到一个form当中去 FrmEquipment frmEquipment = new FrmEquipment (); //form窗体中实现打卡机数据触发事件逻辑 　　 2. 在启动打卡机连接的线程中声明为 STAThread Thread equipmentThread = new