关于商城项目的重新构建购买逻辑

一.废话不多说，打开每一个页面先。

1.登陆页面未改变title

2.index.html

3.商城(title 商城，实际在项目里的名字为require_mall.html)，由于之前原作者的求购商城实在是理解不了他的逻辑，所以自己按照自己的购买逻辑做了这个页面，就是把求购商城的页面做成了商城的内容，然后mall_page.html的内容作为一个心愿商城，用来发布一个商品需求信息。

4.心愿商城 (title 商城，实际在项目里的名字为mall_page.html)，之所以这样改，还是觉得原作者的这个商城页面做的太素了，所以就调换了，之所以html的名字没换还是觉得有点麻烦涉及到很多前后端的跳转就没有改。

5.商城某个商品的详细信息页面（这里以第二个为例，title为‘商品详情’，实际页面名字是require_product_info.html），当然这里的加入购物车是指从userwant这个表里取数据，然后与具体的登陆用户做关联王goodscar表插入数据。

6.心愿商品详情（这里以第一个为例，title为‘心愿详情’，实际页面名字是require_product_info.html）,加入收藏则是往goodscollection这张表插入关联数据，当然这张表原是没有的，因为这是我自己添加的一个逻辑，加入收藏会有一个验证逻辑，一是自己加入过的收藏不能再次收藏，二是自己发布的心愿商品也是不能收藏的。至于上面的加入购物车我暂时没添加这样的逻辑，所以那个商城的商品如果是自己发布的也可以添加到购物车的，我也不知道会不会有人买自己商店里卖的东西，而且是在同一个账户下。算是刷销量吧可能。

二.接下来是几个button的事件了

1.个人信息(title与页面名字均为更改过),确实提交上面存在问题，每次都提交一个字段要烦死人。再就是其中两个字段显示存在错误，暂未更改。

2.这是上架商品到商城页面的一个页面，原作者的话，图片上传回显啥的都有问题也不能提交，之后自己专门添加了一个用来上传图片的Controller，然后把它作为一个单独的页面，以后那个页面需要调用，直接内嵌我写的那个DIV即可。

接下来就是提交后的自动跳转到回显页面，也就是商城页面的结果如下：

接下来看刚上传商品的详情如下(目前的话修改button还没绑定事件，Controller也没写,service实现类应该会有具体的更新数据方法到时候直接调用就行了)：

3.发布心愿信息（对应的html的名字是publish_product.html），他与上架商品的逻辑基本一致，就是少了多了个成色字段。从它的html名字就可以看出来其实当初原作者是把这个也面作为一个发布商品的页面的，不过后来鸠占鹊巢，它现在是作为一个发布心愿信息的页面了。对应的插入数据的表是userwant。

上传成功之后是自动跳转到管理我的心愿页面的，页面的名字是：my_publish_product_page.html

这时心愿商城也会有你添加的心愿信息如下：

当然由于之前的作者添加过详情页面跟删除修改功能就不需要我写辣。省心。。.
当然，按道理来说这个收藏按钮是不应该有的。因为这是自己本人添加的一个心愿信息。这里需要做判断。

4.我的购物车，这个页面改动不大，我还是调用的原来的Controller，然后只是改变的返回的list放的泛型类型,当然更改返回list是需要改变调用DAO的，原本用的是查询ShopInformation这张表，由于页面调换了，商城页面显示的是userwant的数据，所以查询也改为了userwant的数据了。目前结算按钮还未添加绑定事件，更没有写后台结算逻辑。打算只写一个商品数量的变化逻辑了，一旦发生结算业务就把购买的商品的id按照购买个数在userwant页面进行相应的减法。

5.接下来的‘我上架的商品’跟‘管理我的心愿’的页面如下，之前的按钮跳转应该涉及到了，就不多BB了


6。剩下的’实现Ta的心愿’,暂时未写页面。阐述这个按钮的意思是，类似于一个收藏吧，场景应用就是，1.假如你是一个商家，在心愿商城上看到了某个用户发布了一个商品需求信息，你作为商家刚好有用户描述的商品，你可以直接发布商品到商城，这样用户就可以在商城上看到后添加到购物车进行购买了。2.你正好没有这件用户描述的商品，你可以先把它收藏起来，然后等你有货之后再通过发布商品发布到商城。

由于时间还算充沛,就还是实现了一个简单的支付逻辑。就是在购买时，需要操作的表：
1.account表，这张表记录着账户的金额信息。就在需要购买的时候，顾客的账户会对每一个他所购买商品的商家的账户进行转账业务。当然这里如果运用JDBC的事务管理和AOP异常切面再适合不过了。就是一旦发生转账行为，假如A向B转账 如果A账户钱少了 但是B账户并没有受到A账户所减少的钱就会抛异常并回滚事务。
2.userwant表，在支付的同时也需要操作这张表，主要是这张表的QUANTITY字段,就是货物剩余字段。买多少个就减少多少个，当然这也时针对多个商家的。
3.orderform表，也就是订单表，在这些操作完成时生成N条订单信息用来前台查询时展示。
按道理来说这三个业务是一个不可分割的整体，也应该使用事务来进行管理。

首先看商城这两个商品的数量

再分别把这两个商品加入购物车


然后回到userwant表，找到对应的商家ID

再到account表找到相应的账户

然后回到购物车页面进行支付

点击结算后:

点击确定后：

再回到账户数据库查看另外两个商家是否收到钱

再回到首页查看商品数量是否减少

为了早点帮她做好,我也是我在家里很久了啊

接下来时订单处理页面
还是先从加入购物车开始吧，

这里选择NIKE跟礼服 加入购物车

在支付之前先到订单列表看一下

目前订单列表为空,于是我准备支付了。

支付时我只单独选择购买了2件礼服，那么先来到订单列表看一下先

订单信息已成功回显，于是再到购物车多购买几件商品试一下

这里又购买了鞋子跟瓶子，再回到订单列表查看

目前都已成功回显，卖家暂未发货。于是登陆卖家账号呗

卖家账号的顾客订单下获取到顾客的订单信息，于是卖家一一进行处理呗。


每处理一个后台更改display状态。暂时只处理2个订单，我再回到顾客的账号下，再看订单列表有什么变化

卖家处理过的订单发货状态为已发货了