jgdabc的博客

id当然就是购物车的主键id,name当然就是所选的菜品或者套餐，然后image就是其实作为图片路径，将来要展示具体的图片的时候，我们就会需要这个字段的属性，然后就是user_id，这是比较重要的一个部分，因为这个购物车表中会添加很多的数据，我们需要按照片不同的用户来区分不同的用户的购物车，当然没非常重要的就是，如果用户登录到前台页面，所展示也就是他的id下面所关联到的购物车数据。那么后台我们需要做的是什么，首先需要做的就是一个添加，因为我们刚刚做的就是一个添加的功能。具体的呢，就是这样的一些数据，如下。

这两个方法也是写在js里面，一个是获取菜品的数据，一个是获取具体的购物车数据。这里进行了对分类类型的判断，这里其实就可以判断出来就是type =1，那么就是属于菜品的分类，于是去调用查找菜品分类下面对应的数据的具体的方法。当我们点击到对应的分类的时候，就会对应到这个方法，然后就还是按照这里去获取对应的分类数据。于是我们跳转到这个界面，也就是我们的移动端的点餐的主界面，大体的话，就是这样的一个界面。这里就是获取分类的第一个分类，这个，所以从这里看，其实就是获取默认的分类中的第一个分类。

pc端的后台管理我们剩下有订单明细还没有进行开发，由于订单这边需要移动端下单后才可以看到订单，所以我们需要去先在移动端开发一些功能后，再回过头让订单这边进行一个展示。首先移动端开发的话，我们首先遇到的应该就是登录的问题。移动端登录这边我们验证码发送的话我们这边采用qq邮箱的验证码进行登录。既然是用户登录这里的话，其实我们还需要这样对应的数据模型。我们先看前端页面代码这里给到的登录页面这里，其实我们可以稍微修改一下，之前这里是提示的输入的手机号码，我们这里要用qq邮箱验证登录的话，其实我们可以要求输入邮

在这里呢，还是按钮绑定的方法，批量停售和批量启售，如果我们代码当中绑定的方法里面传过去的是1,那么就是启，0就是停售。基本上在套餐这里的模块我们只剩下简单的对售卖状态更改了。停售，启售，批量停售，批量启售。所以总的来说，其实都是绑定的是同一个方法，那么我们就具体的去查看这样的方法。我们先来看前端界面，当前，还是在浏览器中直接调试也是没有问题的。为了更加明白整体的逻辑，我们就还是先看页面设计代码。在这里我们就能清楚的看到路径和具体的请求方法了。然后我们这样去写代码就可以了。还有这里就是单个操作的按钮。

我们找到前端这里关键的一行代码，这里的意思就是如果我们进行的是批量删除，那么就把checkList作为参数传递进去，如果我们没有进行批量删除，只是选择了单个进行删除，那么就将这个单独要删除的id进行传递进去。我们可以这样去规定一下，如果套餐正在售卖的话，我们就不能删除，否则我们在删除套餐的时候，其实也还是需要删除套餐关联下面的菜品的数据。在套餐这个模块，我们已经完成的就是套餐信息的分页查询，以及套餐信息的新建与修改这些功能。可以看到这里的单个删除和批量删除绑定的是同一个方法名，然后传递的参数是不一样的。

首先这里是一个自动调用的挂载的，然后挂载这里就是有一个this.id尝试获取url定向来的id这个字段参数，我们前面已经看过了，这个字段其实已经传递过来了，那就是套餐的id。下面这里就是这个具体的跟进的方法，这个方法其实就是包含了两个操作，是根据传参来决定的，我们修改这里传入的参数不是add，所以会定位到下面的修改套餐这里，这里这个添加菜品具体的方法就写在这里了。继续往下看，这里就是我们的具体的方法，prams就是我们刚刚赋值给的参数，那么我们修改的数据也会被绑定到这里，这样就成功完成了数据的绑定传递。

下面的是菜品列表这里，其实我们的套餐和菜品关联的实体类中没有这个列表的，所以不能对应上，前端给你一个列表，我们就需要先接收到这个列表，然后再去列表里面的属性和其对应的值，然后在对应实体类具体字段赋值，然后再保存到数据库，这样才可以。，这里的setmeal_id在菜品列表这里并没有传来，所以我们需要在套餐保存后，我们在保存菜品到关联表的时候，也要将套餐的id获取出来，然后set到菜品关联的属性上，然后再以前保存，这样才可以。第一，查询查询套餐分类，第二，查询菜品分类，第三，查询菜品分类下面具体的菜品数据。

有关数据的展示的问题，我们会发现，在setmeal这里其实并没有这个套餐分类，而在前端页面，要展示的话是需要这个字段的，所以我们需要拓展道这个属性，然后菜品数据这里也是一样的道理，我么之后再添加套餐的时候，需要添加菜品的一些信息，以及其它的操作，都需要这个属性。首先这里是套餐的功能开发，我们在设置数据库表以及之后的实体类的时候我们需要关注的就是套餐本身的分类以及套餐下关联的菜品。这样的分页查询我们还是按照之前的逻辑,当我们打开这个前端页面的时候，这里的方法这里其实还是进行了挂载的自动加载。

所以到这里我们其实需要完成售卖状态的修改，包含的就是批量售卖状态的修改，另外就是单个状态的修改。可以从这里看到，这里其实对菜品信息的启用和禁用是根据前端这里scope.row的status返回值来进行设置停售和启售的。这一部分功能是课程没有去完成的，但是其实是比较简单的，我们需要去完成菜品的启售和停售。我们可以发现这里其实也是调用到了同样的绑定的方法，只不过它这里其实传了一个字符串的1。执行之前的项目，我们要完成的就是这里的这个售卖的状态的更改。所以其实在数据库的菜品的表的设计当中就有这样的一个字段。

我们看菜品的基本信息是有id的，我们可以先将菜品添加保存，然后给DishFlavor设置对应的菜品id，那么我们就可以去用流的方式去遍历处理口味，然后将每个口味对应的关联菜品的id set上去。回忆一下，所以我们打开数据库的这个分类表去看看，你看这里就是我们的分类，根据type的值来区分是套餐的分类还是菜品的分类。需要注意的就是图片的这个回显就是我们之前写过的，要结合到文件的上传，文件上传的其中的一个转储，这个路径一个要写对。前端页面就进行了对图片下载的方法的请求，其实还是调用到我们之前下载图片的代码。

按照图片上传以及前端展示的逻辑，我们需要将图片上传上去，然后将文件进行一个转存。所以啊我们需要转存持久化，然后就是下载，下载的话就是通过流的方式在前端展示读取到浏览器。类似这样，我们的前端的几个页面都有需要上传图片。下面我们来看文件下载的后端逻辑。我们还是按照前面分析到的请求逻辑，下面我们来完成文件下载的逻辑。其实我们刚刚看到的前端上传图片的前端代码就给到了上传的图片的请求路径和下载的请求路径。文件上传的前端页面我们使用到的是spring-web对上传代码的一个封装。至此文件的上传和下载的代码开发完成。..

那么从该页面来看，前端这里其实菜品是关联了口味这些数据，并且前端保存了一些预备的临时数据，我们进行添加菜品的时候要多口味进行选择，然后提交给后端。所以我们得出一个要求就是一定需要有一个菜品和口味的关联的表，所以我们就会想到还需要新的实体类，其实数据库设计的时候具有对口味表的提供。我们现在需要去改造一下菜品的service类，然后我们改进一下dish 的service下面的具体的保存的方法。其实还是和之气前的一样的关联的方法，就像套餐和菜品的关联的方式一样，通过在一张表中对应到对方的id。

其实你看它前面有一个泛型的修饰，我们之前的泛型是Dish这个实体类，如果我们直接拷贝过去的话，是不符合我们扩展的实体类泛型类型的，所以我们最终单独对其属性进行处理，将最终收集起来的数据设置了进去，这样就会符合一个2泛型的要求。然后放行下来到了页面展示出来，图片没有展示出来正常吗，是因为我们没有设置图片数据文件上传这些操作，它是具体的图片数据没有出来，但是我们的菜品分类却是空的。还是按照原来的分页查询的类似的操作，在vue点到这个页面的时候会自动执行一个分页查询。于是我们可以进一步的去做这个分页条件查询。..

所以点击修改的时候会展示出来这样的一个表单框，然后数据回显了出来，我们可以修改，按照vue模型的双向绑定的话，我们填写的话也可以传给数据模型，然后我们点击确定，提交，提交给后端，后端然后做出数据的修改的功能开发，就是这么一个过程。我们点击修改确定之后，他会首先执行的就是我们前端看到的这里的修改的请求，同时当后端正确响应后，它会再次做一个分页的查询。负载呢，就是我们修改框最终提交的这些数据，如果你什么也没修改，那么就还是原来的数据。我们要做的就是对分类模块这个功能这里的修改的页面的一个完善。...

在数据库表中给菜品表和套餐表设计了字段叫做categoryId,这个属性字段可以作为与分类关联的依据，在具体的分类的表中，与菜品分类和套餐分类，他们有自己的id,我们判断是否关联的方法就是比对菜品表和套餐表当中的categoryId和分类表具体的分类的id是否一样，一样的话就说明有关联。我们可以自定义一个异常，当查询出来关联到菜品或者套餐的时候，我们就抛出异常，这个异常我们去自定义就好了。于是在用到mybatisplus的删除的操作的时候，我们需要去做一些判断，那么我们句需要去重新定义remove方法。..

调用的是这个方法，然后上面的具体的表单就展示了出来。然后我们去具体看这个方法。截取了一部分这个方法，其实这个方法写了很多，其实修改的话也是调用了这个方法。这里是上面两个按钮的具体的展示，它们其实绑定了同一个方法，只是方法传参不同。从下面找到的这段看的话，其实还是按钮绑定了方法，调用的也是同一个方法，只不过是具体的传递参数不一样。其实这两个表单的结构是一样的，只是在标题的名字有所区分。传递的是json格式的数据，这样的参数体，所以我们用RequestBody。在这里的负载呢，我们也可以看到具体的传递的数据。.

在对页面的员工信息处理完之后，我们就开始去处理下一个功能，对分类的功能做一个整体的开发。这是我们的分类管理的界面，现在我们去对界面的分类的展示做一个开发。初次打开这个界面的时候一定会有一个自动的分页查询，所以我们可以去着重去看是否有自动执行的方法或者是挂载的方法。我们找到了这个具体的请求路径，其实这个具体的请求路径是卸载一个js里面的.我们这样就可以找到怎么设置Controller的路径，以及通过上面的分析知道需要提供哪些参数了。我删除了这些方法里面之后需要的一些拓展的自定义的方法，为了不影响本次的说明。.

公共字段填充的必要性就是当我们在我们执行一些具体的操作的时候，我们需要更新字段，比如具体执行相应操作的时间，以及可能需要的更新或者修改者的id。这些我们可能需要每次都需要去填写，但是我们可以让其统一的去执行，比如我们执行修改或者插入类似的操作的时候，那么时间就会自动获取到当前时间，然后填进去，依次类似。MetaObjectHandler接口是mybatisPlus为我们提供的的一个扩展接口，我们可以利用这个接口在我们插入或者更新数据的时候，为一些字段指定默认值。对需要做公共填充的字段属性添加响应的注解。..

但是这样会出现一个问题，前端js并不能正确处理id，因为我们的id根据生成策略它是19位的，但是在分页查询的时候后端给前端传给19位long类型的id只能被js处理到16为，这样的话，在我们这里前端获取id提交给后端的时候也就和本来的id对应不上了，于是我们必须想出一种解决办法。于是这样，我们可以写一个统一的方法，那么两者的请求路径和方法是一样的，于是我们可以遇见一个接收参数的形式。我们用实体类型employee来接收前端提交的参数，因为这些参数我们的实体类都有，这样我们就可以进行一个统一的接收。...

目前开始写初步部署，因为我是完全用jar包部署的，直接部署的。没有放在docker容器中，所以我先这样做了。因为目前项目还是存在许多不足的地方，只是功能上的不完善，所以目前开始写jar包的初始部署运行。一遍在这边练习部署的命令和docker容器，一遍从头开始梳理瑞吉外卖的整个过程，我觉得一定就闭环了。我相信一定要自己试一遍，不要眼高手低。......

如果用户请求的这个路径直接就是登录和退出我们就没必要进行拦截处理，这个过滤器主要是未登录用户的非法访问的处理。点击退出的本来就已经登录吗，不需要验证，要登录的没有进行非法访问，其他的是各种资源路径我们没有必要去验证。思路是这样的，我们正常的思路是访问登录界面然后输入信息验证，然后我们到达管理界面。还有一个判断就是如果你能获取到用户id就可以判断已经登录了，因为我们之前在用户登录的时候会存储他的id在session。所以我们这里也进行一个判断，获取这个值，没有获取到就是没有登录，获取到就是登录了。...

这个项目是基于springboot+mybatisplus作为核心的开发项目。是一款外卖开发项目。本次还是从后台管理界面进行开发的，前些天敲完了基本，后来还是给自己遗留了一个bug,项目还有没有完善的部分，现在就从写博客这里重新捋一遍。这样也许更有效果。很多人觉得简单，但是我觉得这是一个非常重要的项目，是一次真正意义上的前后堵的人项目。很值得我们去多家回顾练习。本篇从后台的一个登录界面开始。这里前端页面已经给好了，但是我们后端还是需要去看懂。这是我们需要的数据表。用户登录啊需要这个表，employss，默

ruleForm是上方页面的数据绑定，里面就是我们员工的信息，这里的知识点就是vue的数据模型的双向绑定。我们在表单上进行的数据修改或者添加也会同步到我们的数据模型，所以我们实际上就是将自己填写的用户数据进行了一个分账类型的提交。一定有一个保存的按钮，保存的按钮绑定到具体的方法，然后在这个方法里面我们就可以找到我们去具体处理数据的逻辑。其实我们之前都看过，但是表单自然是不会去展示密码的，以及像修改时间，修改者这些等等，密码我们做成糊另外的处理，其他的其实属于我们上文提到的公共字段，所以我们让它自动填充了。.

不过还是去看看前端的界面，明白一个大概的流程会更加方便我们去操作。可以注意到这个方法的泛型是Page,也就是我们最后返回的也是Page类型的pageInfo。按照后端的逻辑的话，我们其实是可以直接先去运行这个项目，因为我们之前完成了的登录退出功能。你看这些字段就是我们需要的，所以我们要用Page这个泛型。其实刚进来这个页面你是看不到数据的，因为这样进来台管理页面它其实会做一个自动的分页查询，但是这个后端的功能我们还没有做。index的这个界面，我们找到这个界面。我们在网页检查这个登录的动作就可以。...