会议预约系统设计中的思考
会议预约系统中的思考
做会议预约系统，在没有经过深入的思考，就开始编码。在实际过程中，确实遇到不少问题。这种脚踩西瓜皮，滑到哪算哪的方式，并不是一种好的设计方式。在产品成形之后，再根据用户的临时需求，临时的增加一些功能，修改逻辑，确实不是一种好的设计。
比如，最终的权限设计。本来好好的ACL权限设计，其实倒也没有什么问题。但是，运用在产品上，感觉非常的不规范，没有经过系统的设计，临时需要什么权限，临时加权限。需要屏蔽权限，临时的更改代码。其实这些权限的功能，理论上应该在后台的数据库里面进行统一管理，而不是采用更改代码的方式，去满足用户的设计。
一套系统，要上线三个客户端，而三个客户端，要维护三个前端的代码、三个后台的代码，除了个别的模块代码，共用了部分后台代码。虽然完成了用户功能，后台、手机端这种分离的代码，不能很好的形成统一的管理。更不要说后期的代码维护。基本上每个模块都是独立的设计，公用的操作，没有独立出来，而且又没有代码生成器。代码风格确实有点不统一。（如：json返回值code的表示，有的人习惯用0表示没有错误，而有的人喜欢用1。其实个人感觉，应该用0来表示没有错误。因为没有错误只有一种可能。失败，却有很多可能。）
后台的php代码，没有设计一些必要的全局变量。如根目录、调试模式等。没有设置放置运行过程中的临时变量。
虽然后台没有很大的访问题量，但是在一些不常更改的地方，应该考虑使用缓存系统。比如，部门结构，这种递归嵌套循环，是很耗时的，而部门往往是最不经常变化的，应该采用缓存。
系统，没有按照正规的模式，设计模型类，全部是静态类的方式调用。这种方式，其实只是利用了静态类的简单包装功能。并没有深入的面向对象的设计过程。其实框架提供了很多有用的功能，并不需要人为去手动添加的。合理的使用功能。如数据验证、简单的数据查询功能等。这些完全不需要手动去写。只需要new 模型的实例，或者像ThinkPHP中的那样，用D、M函数来自动生成。简化功能。
最终这个系统，就是简单的使用了$db->query的功能，连fetchCol等函数，这些框架本身能完成的功能，还需要手动编码。无疑增加了代码量。另外，手机端的会议预约系统，独立的小函数确实多，但是基本上，也没有办法复用。而且阅读代码的时候，由于函数调用的层次过多，其实并不有利于把握整体的代码。
顺便说一句，产品越着急，其实越不适合培养新人。勉强的培养出来一个，其缺少必要的知识，成长的慢。而且需要花费大量的精力。确实得不偿失。
问题总结
数据验证问题
数据删除时，应有相应的删除依赖。
登录问题
检测用户是否登录。按一般的web设计，如果用户没有登录成功。应该让用户跳转到用户登录。但是，后台却是采用了10秒轮询的方式。定期从后台访问session是否登录。如果没有登录，ajax请求到没有登录，直接跳到登录界面。
关于这个设计，其实在code里面统一设计，如果返回某一错误码，并返回操作的附加值，让其跳转到指定的页面。针对一些需要显示内容的页面，也应该设置统一的显示界面。另外，也需要返回一些js代码，能让其动态的直接一些操作。让操作更具有灵活性。code指定了错误类型或者操作类型。数据删除依赖问题
有些数据删除时，其实是有验证的依赖关系。这种设计，其实应该在最开始的时候，进行考虑。向这种检测，应该有个统一的功能进行负责。而不是侵入到代码。
数据插入、修改时的唯一性验证问题
其实这也是常见的功能。在数据入库之前，统一进行检测。检测的代码如：
<?php $sql='select * from table where id!=updateId and name!=name'; $msyql_query($sql) //如果检测到资源，提前返回。操作日志
操作日志侵入正常代码，比较厉害。其实应该统一到日志模块中。另外，这种操作日志，其实是有点丑陋。
设计中的闪光点
最开始的时候，调用三方接口，是散布在正常的代码之中的。而且设计的是面向过程的函数调用方式。后来更改为静态类的设计。因为整个系统中的静态Utils类较多。在后来，其实有心想更换为单例模式，但是切换的代价太大，导致主观上不太想变更。而且，这个消息通知模块，功能设计的也不是特别的合理。尤其是，为所有的消息通知都写了一个特殊的方法。这是错误的。应该发送各个消息，其实过程是相通的，这个应该有一个集中处理的函数，将配置项读取，然后去调用。现在问题突出表现在：阅读难度大，增加一个发送消息，又要重复代码。（虽然发送了两类消息，其实这个也能抽象成一个。）
出现上述问题，最重要的还是，代码设计功底不强，抽象能力较差。重复做机械的操作。如果套上设计模式，可能会更好一些。这个值得以后去思考。
建议
机械的检测的代码，应设计成代码生成器的模式，或者抽象出可复用的。
代码应该独立成模块，而且相关的操作，应该放在一起。比如后台的会议预约系统，为了临时的快捷，将发布会议等功能，也放到此模块中。增加了代码的函数，不利于理解。
增加抽象能力。前端，针对一些常见的操作，应该进一步操作，如：ajax请求，消息提醒等。应该进行抽象。对于一些简单的模块，应该抽象出一个父类组件，子类只需要进行配置，即可使用。（将部分业务跟组件进行合并，进行继承。子类会很干净，整洁）