关于制作图桌互联网订桌系统的思考

这个东西算是我也做过的比较正经、完善的一个web应用，图桌互联网订桌系统是将影院选座与互联网订桌相结合的互联网订桌应用，也是我这次参加三创赛的项目实体。

制作这个web应用，前端应用jQuery插件，后台应用Struts，Spring，mybaits框架进行搭建，这也是我第一次尝试SSM框架，Struts框架确实带来了很多便利，可以将URL映射到方法、直观简单的传递参数，mybaits框架也确确实实的简化了数据库操作流程，但是我还没体会到Spring框架带来好处，在这个项目中，我只是简单的使用了注解注入，但是它代替的不过是new而已，我想注入的好处，也许在多人合作开发中，开发者不需要在意从外部引入的类叫什么，怎么实现的，只需要知道他实现了哪个接口就好。接口可以让我在没写DAO层的时候就写好service层，而实现哪个DAO类只需要换实现类即可，Spring注入简化了这个过程。

Spring还有另一个特性，切片式编程，我从书中的理解是可以在多个地方多次调用一个代码段，这确实是进一步的抽象，这次我并没有应用这个特性，会在以后的练习多留意。

关于SSM框架的配置问题，着实头疼了一阵子，这次我也只是只知其一，不知其二的照葫芦画瓢，复制粘贴，未来一段时间，我要看看研究研究每一个配置标签是做什么的，是如何实现的。虽然说我不需要知道每个积木如何制作，但是只有摸清积木的形状和局限，才能得心应手的使用他们。

程序架构的时候，我设计了四层，表现层，逻辑层，服务层，数据处理层，表现层与逻辑层采用Ajax的方式沟通(我这次居然愚蠢到Ajax整个页面，导致后面修改极其困难)，逻辑层是各种功能的action，action内进行参数过滤和基本的逻辑判断，随机调用服务层封装的高数，服务层通过数据处理层的方法与数据库交互。

这次后台设计中，我只设计了一个service类和一个DAO类，所以在后来修改、增加功能的时候，也是相当头疼，所谓吃一堑长一智，Service和DAO，应该对需求尽可能详尽的分类抽象，这样在修改功能的时候也方便我快去锁定目标代码区域。

前端开发的更乱了，我是每个页面单独编写的，写了7、8个HTML，为外部引用了7、8个JavaScript和CSS，而后期又采用Ajax的方式从body将整个页面load进来。所以，我想改的时候往往忘了改那个页面的哪个样式或者哪个脚本。

需求分析也存在问题，一个订桌的应用竟然在设计数据库的时候忘记增加桌位号字段，很多功能也没想明白就开始制作，导致需求不断改变，在开发之前，我应该从使用者的角度尽可能去想我需要什么功能，在从实现某一功能的角度去想我需要如何实现。不妨从每个一个功能出发，将表现层，服务层，数据处理层的方法思考出来，再将相似过相近的，抽象在一起。先想明白，再开发。

总和来讲，这个web应用是一个金玉其外败絮其中的辣鸡工程，挺好的创意让我这个菜鸟写的太水了，但是我也从中得到了很多反思和收获：

1.需求分析时先尽可能描述使用者需要的功能与元素，再从每一个功能出发思考每一层需要的方法，最后将同一层，功能相似，或作用相关联的方法抽象起来
2.前端设计时，规范CSS命名，开发时不妨暂且将CSS与JavaScript先放到HTML内，再对每一页通用的CSS进行抽象，放到外部引用。Ajax不要引入整个页面，只需要将需要的部分引入到一个页面div即可，在JavaScript中切换div，同时休息请求等待时间的用户体验。加强前端框架的学习。
3.后台设计时，SSM框架配置的熟悉度还有待提高，同时加强将需求转化为计算机可识别语言的能力，增强抽象能力，每层多分几个class。

我一定会在以后重写这个项目的……