[b]1、技术概述[/b]
1.1 struts2.2.3 + spring2.5 + hibernate3
1.2 mysql5.5 + tomcat 6.0 + jdk 1.6
1.3 前台：jsp + jquery，标签用了JSP标准标签库：JSTL标签库。UI框架：jquery EASYUI 1.2.4
1.4 另外加了对URL进行重写的小工具：urlrewrite
1.5 前台表单校验 formValidator4.1.3
1.6 万网域名 + 阿里云主机
来说说框架，这大概是我最后一个用SSH开发的项目（后来用springmvc+mybatis比较多），SSH框架算不上很好，也算不上差，因为对于较简单的系统来说，都差不多的。
对于jquery easyui框架，我之前大概做过两个easyi的项目，这一次就纯粹是拿来主义。相较于EXT来说，easyui确实是轻量极的。
[b]2、项目需述描述[/b]
是一个二手书的交易平台，相较于其它的二手书的运营模式（传统的基本上是，卖家发布卖书信息，买家搜书，具体去那个卖家进行交易），而这个项目呢，在运营模式上进行一定的创新：
即
[color=blue]卖家上传书籍的数量，买家只是在资料库中买入该书（具体是不知道卖家是谁的），然后网站本身去分配卖家的资源（按一定的算法），由网站去配送书本，单独和卖家以及买家进行结算。（比如卖家回收家是2.5折，销售价是3.5折，网站赚中间的这个差价）。[/color]
[b]3、核心技术[/b]
网站管理员在收到订单后，要对订单上的书进行自动分配卖家，这个算是整个网站的核心处理机制。
这里的规则概括下是：（用递归写的）
a. 若买家买多本不同的书，先匹配手中书种类多的卖家。
b. 同一类书本多的卖家先得到分配。
c. 若一样多的话，看上传的时间先后。
其它的功能都比较常规，简单列举下：
[u]前台：[/u]
【首页】首页、学校列表页、用户注册、登陆
【搜索】我要买书、我要卖书
【我要买书】书本展示页、购物车、在线支付
【我要卖书】书本展示页、前台自助上传书籍、帮助
【用户中心】已卖书籍、已买书籍、我的订单、已上传书籍、我要上传、我的资料、修改密码
【我要寄售】书籍寄售功能、寄售查询、帮助
【一键回收】一键回收功能、帮助
（寄售和回收功能是二期开发的，都只是信息上的记录。）
[u]后台：[/u]
【用户信息管理】用户信息管理、用户上传书籍列表
【库存管理】库存管理、书籍审核、寄售/回收
【配送管理】等待付款、等待分配、等待配送、订单列表
【系统信息管理】学院设置、专业设置、管理员管理、角色管理、学校群组列表、学校管理、学校首页图片管理、学校公告图片管理
[b]4、网站接口接入[/b]
4.1 人人网登陆
4.2 支付宝支付接口
4.3 各大社区分享
[b]5、开发周期[/b]
5.1 一期项目主要就是整个网站的开发，针对的是单个学校的卖书。[u]2012年12月，为期一个月。[/u]
5.2 二期项目主要是从单个学校扩充到多个学校，学校间可以形成群组，进而实现库存共享。[u]2013年4月，为期一个月。[/u]
5.3 三期项目主要针对前台的界面的美观度上进行修改。（一期的CSS是甲方自己提供的，确实很难看），功能上的修改就是可以去京东上抓取图书，进而丰富网站的图书资料库，卖家可以自己修改定价等，[u]2013年8月，为期一个月。[/u]
（按业余时间算：周末或平时下班后。）
[b]6、网站数据[/b]【截止2014-02-03】
6.1 运营时间：2012-12-29 至2014-02-03
6.2 订单总数 1608
6.3 共交易书本数 3017
6.4 交易总额 199893.5 其中支付宝交易 3275.7
6.5 共接入学校 12所
6.6 书籍导入：13317本
[color=red][b]7、存在的问题或反思[/b][/color]
这块比较重要。
7.1 前台的搜索做的还不够强大。针对这块一直没有好好的优化过，还是用了传统的SQL的LIKE语句。效率上跟不上。
7.2 一期做的时候完全没想过后来会扩成多个学校，导致二期的时候很麻烦，所有表都要加上学校ID字段，这个是否可以做到在刚开始做的时候就拥有更多的扩展性?
7.3 库存的记录问题。关于书籍的库存，刚开始的做法是在book表中加了库存数量字段，读取都用该字段，若卖掉一本书，则修改此字段记录，后来发现这样的准确性有待提高（取出数据，数量相加减，再保存，期间有数据表的并发现象）。处理办法是前台列表的读取用的是该字段时实查询，而更新该字段的时候，用的是实时统计的书籍数量）。有没更好的办法?
7.4 订单的并发性问题。目前的处理办法是在下订单的时候，再去查询一遍库存，若有库存，则让提交，则没有，则报错。不知道其它公司是怎么做的，是不是要锁表?
[b]8、关于技术上的总结：[/b]
8.1 项目是拿来主义（从另一个项目中直接拷过来的)，所以代码的冗余度很高，这个习惯非常不好。这可能跟这项目的紧急程度也有关，说明平时不忙的时候要整理下框架问题。
8.2 在二级缓存方面完全没有优化。
8.3 首页本可以考虑图片延迟加载等技术。
8.4 写代码时要形成注解、规范的好习惯。必要时文档要整理好。
8.5 网站没有基于SEO方面的优化。
[b]【写在最后的总结】[/b]
这算是我接到的第一个比较大的项目，我在WEB开发上经验不算太丰富，负责过的网站前后大概5个左右。这项目的甲方是在校大学生（当时是大三），挺有志向的几个学生，我接手网站后，大概因为项目周期（一期就1个月时间）、经费的问题，没有太投入新技术（之前就比较熟悉SSH框架的开发，当时为了方便，很多东西都沿用了以前的代码），对于自己的个人能力方面来说，我平时比较注重记录问题，所以还是有一定的提高，但不是非常明显。
做的比较好的方面就是，在这个项目上，我认识到文档的重要性，所以很多想法、功能或是数据字典等，都有很好的记录。
关于网站建设方面，感觉还是比较遗憾的，没有100%的投入，很多已经存在的问题没有给甲方解决，可能跟时间、经费、个人热情都有关系吧。
1.1 struts2.2.3 + spring2.5 + hibernate3
1.2 mysql5.5 + tomcat 6.0 + jdk 1.6
1.3 前台：jsp + jquery，标签用了JSP标准标签库：JSTL标签库。UI框架：jquery EASYUI 1.2.4
1.4 另外加了对URL进行重写的小工具：urlrewrite
1.5 前台表单校验 formValidator4.1.3
1.6 万网域名 + 阿里云主机
来说说框架，这大概是我最后一个用SSH开发的项目（后来用springmvc+mybatis比较多），SSH框架算不上很好，也算不上差，因为对于较简单的系统来说，都差不多的。
对于jquery easyui框架，我之前大概做过两个easyi的项目，这一次就纯粹是拿来主义。相较于EXT来说，easyui确实是轻量极的。
[b]2、项目需述描述[/b]
是一个二手书的交易平台，相较于其它的二手书的运营模式（传统的基本上是，卖家发布卖书信息，买家搜书，具体去那个卖家进行交易），而这个项目呢，在运营模式上进行一定的创新：
即
[color=blue]卖家上传书籍的数量，买家只是在资料库中买入该书（具体是不知道卖家是谁的），然后网站本身去分配卖家的资源（按一定的算法），由网站去配送书本，单独和卖家以及买家进行结算。（比如卖家回收家是2.5折，销售价是3.5折，网站赚中间的这个差价）。[/color]
[b]3、核心技术[/b]
网站管理员在收到订单后，要对订单上的书进行自动分配卖家，这个算是整个网站的核心处理机制。
这里的规则概括下是：（用递归写的）
a. 若买家买多本不同的书，先匹配手中书种类多的卖家。
b. 同一类书本多的卖家先得到分配。
c. 若一样多的话，看上传的时间先后。
其它的功能都比较常规，简单列举下：
[u]前台：[/u]
【首页】首页、学校列表页、用户注册、登陆
【搜索】我要买书、我要卖书
【我要买书】书本展示页、购物车、在线支付
【我要卖书】书本展示页、前台自助上传书籍、帮助
【用户中心】已卖书籍、已买书籍、我的订单、已上传书籍、我要上传、我的资料、修改密码
【我要寄售】书籍寄售功能、寄售查询、帮助
【一键回收】一键回收功能、帮助
（寄售和回收功能是二期开发的，都只是信息上的记录。）
[u]后台：[/u]
【用户信息管理】用户信息管理、用户上传书籍列表
【库存管理】库存管理、书籍审核、寄售/回收
【配送管理】等待付款、等待分配、等待配送、订单列表
【系统信息管理】学院设置、专业设置、管理员管理、角色管理、学校群组列表、学校管理、学校首页图片管理、学校公告图片管理
[b]4、网站接口接入[/b]
4.1 人人网登陆
4.2 支付宝支付接口
4.3 各大社区分享
[b]5、开发周期[/b]
5.1 一期项目主要就是整个网站的开发，针对的是单个学校的卖书。[u]2012年12月，为期一个月。[/u]
5.2 二期项目主要是从单个学校扩充到多个学校，学校间可以形成群组，进而实现库存共享。[u]2013年4月，为期一个月。[/u]
5.3 三期项目主要针对前台的界面的美观度上进行修改。（一期的CSS是甲方自己提供的，确实很难看），功能上的修改就是可以去京东上抓取图书，进而丰富网站的图书资料库，卖家可以自己修改定价等，[u]2013年8月，为期一个月。[/u]
（按业余时间算：周末或平时下班后。）
[b]6、网站数据[/b]【截止2014-02-03】
6.1 运营时间：2012-12-29 至2014-02-03
6.2 订单总数 1608
6.3 共交易书本数 3017
6.4 交易总额 199893.5 其中支付宝交易 3275.7
6.5 共接入学校 12所
6.6 书籍导入：13317本
[color=red][b]7、存在的问题或反思[/b][/color]
这块比较重要。
7.1 前台的搜索做的还不够强大。针对这块一直没有好好的优化过，还是用了传统的SQL的LIKE语句。效率上跟不上。
7.2 一期做的时候完全没想过后来会扩成多个学校，导致二期的时候很麻烦，所有表都要加上学校ID字段，这个是否可以做到在刚开始做的时候就拥有更多的扩展性?
7.3 库存的记录问题。关于书籍的库存，刚开始的做法是在book表中加了库存数量字段，读取都用该字段，若卖掉一本书，则修改此字段记录，后来发现这样的准确性有待提高（取出数据，数量相加减，再保存，期间有数据表的并发现象）。处理办法是前台列表的读取用的是该字段时实查询，而更新该字段的时候，用的是实时统计的书籍数量）。有没更好的办法?
7.4 订单的并发性问题。目前的处理办法是在下订单的时候，再去查询一遍库存，若有库存，则让提交，则没有，则报错。不知道其它公司是怎么做的，是不是要锁表?
[b]8、关于技术上的总结：[/b]
8.1 项目是拿来主义（从另一个项目中直接拷过来的)，所以代码的冗余度很高，这个习惯非常不好。这可能跟这项目的紧急程度也有关，说明平时不忙的时候要整理下框架问题。
8.2 在二级缓存方面完全没有优化。
8.3 首页本可以考虑图片延迟加载等技术。
8.4 写代码时要形成注解、规范的好习惯。必要时文档要整理好。
8.5 网站没有基于SEO方面的优化。
[b]【写在最后的总结】[/b]
这算是我接到的第一个比较大的项目，我在WEB开发上经验不算太丰富，负责过的网站前后大概5个左右。这项目的甲方是在校大学生（当时是大三），挺有志向的几个学生，我接手网站后，大概因为项目周期（一期就1个月时间）、经费的问题，没有太投入新技术（之前就比较熟悉SSH框架的开发，当时为了方便，很多东西都沿用了以前的代码），对于自己的个人能力方面来说，我平时比较注重记录问题，所以还是有一定的提高，但不是非常明显。
做的比较好的方面就是，在这个项目上，我认识到文档的重要性，所以很多想法、功能或是数据字典等，都有很好的记录。
关于网站建设方面，感觉还是比较遗憾的，没有100%的投入，很多已经存在的问题没有给甲方解决，可能跟时间、经费、个人热情都有关系吧。
1944
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
