web 记录

真是破天荒啊…我竟然会想要写计算机的知识了

vue+springboot 框架、工程

git版本控制和团队合作

docker和低代码平台 项目部署

springboot+vue也许是最简单最快能做出东西的了,框架自己已经弄好了太多,但…我还是要先吐个槽
好折磨…我是说不知道在干什么写什么,出了问题只能跟着对比步骤、一行行的试着去找代码哪里和视频对不上…当然这样弄没几下我就崩了,更多时间在发呆。
不那么赶的话…可能会好些

前端与后端,简单说的话,前端做样式,后端存数据。
连接是vue通过axios向后端发请求,然后靠java应用调数据库的数据;调出来的数据一般是json形式,通过key-value对应能贴到表格或其他什么地方或者进行些别的什么操作…。
————————————————————————

从vue开始

,vue中提供了许多各种各样的数据绑定传输的小玩意,从{{ }},v-model,v-bind对具体数据的绑定;到用来监听用户鼠标键盘上操作的v-on的click,keyup等等 这可能是最有趣的一部分了...因为要看的东西很短,有实时的交互,和css样式控制结合,很容易弄出些好玩的小玩具出来,再去element ui、bootsrap上找找小零件就可以写网页了

然后是组件这个概念,组件…说的糙一些就是一种高级复制粘贴…和面向对象的“类”这个概念有些相似,里面有数据有函数,或者叫有属性有方法。代码一眼看过的不同就是,vue的数据都要存在一个叫data的东西里、方法都要写在一个叫methods的东西里,嗯这个methods里可以就可以写监控到用户行为后去接收数据、使用router进行跳转、改变样式、使用axios向后台发送请求等一系列操作。
和data相似的还有prop、computed,和methods相似的也有几个但我记不清了。
说了这么多,那它是怎么复制粘贴的呢…最简单是靠对同一组件的多次使用,然而这肯定不够,还有一个操作就是可以在妈妈组件(我就想这么叫)内部去注册别的组件,注册完了就是这个妈妈组件的一部分了,而这个别的组件就被叫做子组件;对了这个注册和上面的data、methods一样也有一个专门的地方就叫components。

…vue的生命周期,然而这个就算了吧,熟悉了好像可以做很多精细操作,我也不清楚,以后看。

然后是router。有一个概念叫做单页面应用,好像是有老多好处了,但我也不懂,我能看见的是,写代码的时候这里的router至少把跳转集成了起来放到了一个地方来整合。超链接的话…可能也有这样的操作?但我写过的都是这里一个那里一个…

对于工程文件,几个命令就能弄好,各种东西的版本好像会放在一个package.json的文件里,给别人的时候把那个node_models删掉也没啥,留着这个json文件几下就能装好。
项目启动,vue这边是maim.js引入App.vue,把它作为一个子组件,然后,创建一个爹中爹…或者妈妈的妈妈?——#app,将App作为子组件;而之后的组件一般都作为App.vue的子组件,或者直接在router的index.js里import一下,直接跳转就好。
————————————————
然后是…是tnnd java ,spring框架。
Java…好些可能我忘了,可能就没学会过。嗯…虽然我都不会,虽然之前还上过Java的课,vue,js都是刚接触,但Java这边是很不熟悉。
非常坏的是这里没有什么小玩具时间,一上来就是工程,虽然它启动只要一个XxxxxApplication就可以了,但依旧需要配置好多东西,maven的pom.xml或者其他的依赖管理,yml或者properties去配数据库连接、改端口…好像也没多少东西?嗯…可能是我讨厌java。但vue几个命令就能弄好,小小一个40MB左右就基本是全部了,可能确实简单些吧…虽然我都不会
对于做小玩具而言…后台这边要做的就是接收前台发来的请求,然后向前台传回数据消息之类的东西、或者根据请求对数据库进行增删改查之类的操作等等。
spring好像是有这样一个不知道叫啥,也是三层的东西。

表现层(User Interface layer):又叫表示层,负责接收用户请求、转发请求、生成数据的视图等。一般表现为界面,用户通过界面输入、查询和得到需要的数据。
业务逻辑层(Business Logic Layer):简称业务层,是针对具体问题的操作,主要是从数据库中得到数据,然后对数据进行逻辑处理,是数据业务逻辑处理。
数据访问层(Data access layer):又叫持久层,该层所做事务直接操作数据库,针对数据的增添、删除、修改、更新、查找等。负责持久化业务对象;

Controller(UI)界面控制层
Service(BLL)业务逻辑服务层
Dao(DAL)数据访问层

Controller是最先接收请求的,接收之后对接受到的请求与写在controller里的请求去匹配,匹配到了就把Service叫起来干活,匹配不到就告诉前台404。
Service干活可能就要访问数据库,访问只能通过Dao提供的接口才行,别问,可能是为了项目方便管理,为了程序健壮性,低耦合高内聚啥的,我也不知道。
Dao这边就是直接对数据库操作了。

src里面还有一堆文件夹,bo、vo、po、dto、pojo、model、entity…但我看里面的东西都和java bean长得差不多?
写的java bean是和数据库里的表对应、写了一堆属性和它们的set get。最简单的是一个bean对一张表,作用是方便复制粘贴、一下子拿出一个东西的全部东西…或者说一条数据的全部数据项。
我看到里面的dto似乎是那种只拿一部分数据项不拿全部、可以减少不必要的数据传输…但那一堆东西的区别我现在是分不清。

框架…我并不了解,什么容器、注入…统统不清楚,我能看到它自己生成了好多工程文件,但它里面怎么跑的现在是没空看,先学会用吧。vue的我也不了解,里面好像也有很多高级的东西藏着,数据代理数据劫持啥的…都qtnmd吧。

嗯,工程说的差不多才能说说具体语法…
@ 注释这个东西我是第一次见,作用可能是告诉框架哪里是干什么的,写在类、实体、方法上的好像都有;这个作用和vue里直接规定的那一堆data、methods、name、component有点像…但我就是看java不爽。
实例化,指类(或者接口)的实现,类是抽象,实例化具体之后才能起作用…一个类在另一个类里实例化,这可能是java最像vue组件注册的那种写法的地方,然而这里的两个类并在java好像并不被看作parent-child…

可能也不是对java有意见,是那天交作业弄得太急给我整破防了…我在想以后的工作生活都是这个吊样吗…nmmd我受不了…
嗯,先到这。

2 个赞

woc两千多字,我可真厉害

棒棒哒

1 个赞

springboot+vue算慢的那一队里.
快的参考ROR…

1 个赞

这些东西,一开始是理解不了的,只有写两个项目之后才能懂.
实践中
bo+dto+model就够用了,分别对应表现层,业务逻辑层,数据访问层

Spring的项目一般分为三层,就是你说的,表现层,业务逻辑层,数据访问层
那么这三层用什么东西来互相交流呢?就是用bo+dto+model.
数据从网络中来,用DTO接受,然后表现层对DTO进行处理,送到业务逻辑层,业务逻辑层把数据变成Model,也就是想办法搞到数据库的操作里,然后业务逻辑层得到数据访问层的数据,处理并返回到表现层

数据的流动变化在各层是这样的:
外部 --DTO–> 表现层 --DTO*–> 业务逻辑层 --Model–> 数据访问层 --Model–> 业务逻辑层 --Bo–> 表现层 --DTO–> 外部

*按理来说"表现层 ----> 业务逻辑层"中间也用的Bo,但是无所谓,实践中表现层一般非常薄,对DTO的操作很少,所以用DTO和其他数据进行拼装即可

2 个赞


:joy: :joy: :joy: :joy: :joy: :joy: :joy:
它终于可以了。。。。

虽然只能查不能增删改。。
vue router 传参数的坏处是不能刷新,一刷新就没了,只能从特定链接里点…

————好了这里解决了,router 的path里也可以填参数

1 个赞


…我要再感叹一下。

一个文本编辑的框框半天弄不好
弄了半天是版本问题,tinymce,找到的教程估计都是5,但竟然下载下来一个6

1 个赞



嗯。。因为数据格式给我卡了老半天。

axios.post(url{data})这样简写发送数据总是会带上一层data:{}这玩意,然后笨蛋后台就解不了了
image
必须得这么写它才是没被中间商套data的json,后台才能解析。

。。其实早就想过这种可能,毕竟后台传来数据都是要先console.log一下再搞,很多时候都tm有好几层data,用的时候得写成this.data.data.data.xxx。。。但苦于不知道怎么看post出去的数据到底长啥样。一看就明白了

神经病啊!要套我不会手动套吗, 弄这么一堆干啥!

但是发现了之后好高兴,甚至有了种我已经游刃有余的错觉。

吐槽一下,找来的这个后台可真是…不知道怎么说,几乎一行自己的代码都没写,全是在导包导别人的函数用…

1 个赞

我真的太厉害了


复制粘贴解决了一个cors的问题
一开始是后台获取不到session里的登录信息的,一直是null,然后有人说是前后端分离项目的跨域问题,然后在前台加了一个 this.axios.defaults.withCredentials = true;然后就继续报错,再然后看着这个 (11条消息) springboot 使用 CorsConfig 和注解,解决跨域问题_小道仙97的博客-CSDN博客_corsconfiguration就整了一个corsConfig,然后就成功了!

后台拿到了登录信息

1 个赞


怪事
image
this.user都有,但this.user.username却undefined

看了看可能是vue __ob__的问题。。
但我这边的问题好像不止这样
JSON.stringify(res.data)是把数据弄成字符串,但用JSON.parse弄回对象时就又变成
{Z1L7RPSEA$J{G}EVDP2L

这玩意了

不是 ob:Observerf的问题,是一种我无法描述但十分诡异的问题。
image
这一项里必须带个Object才能显示
image

这样的就不显示。


嗯。。。它在这儿呢。cnm

。。。现在是2022年7月19日18:17:01

我真觉得这个原作者真的写的一团糟。

从数据库设计开始就是笨蛋,把username当做跳转、关联的字段,那还要什么uid?文章都有封面、用户却没有单独的头像栏?还有一堆无用的表格字段,我知道后来可能用得上,但是连tmd基础都设计不好整这些简直就是……在屎上插花,对,这整个项目给我的感觉就是这样,花里胡哨的东西一堆,好玩的地方乏味可陈。

后端就是把文件生成之后导几个包导函数,用的mybatis还一句sql都不写,基本的用户页写个根据username或者uid把发的帖查出来都不写。几乎就tmd是面向导包编程,各种各样的提供好的不明所以查询模式,一些最常见的功能却反倒是没有,我都不知道那有什么意思。导包也就算了,还都tmd全都直接在controller里导,service和mapper、xml是全都tmd干干净净,生成的文件一片一片都是空的。。

前端啊,我是没拿到源码,我拿到的是一堆html、css文件,但是就算这样也有好多可以吐槽的,前后台简直一点关系都没有——界面风格差异巨大、相互的跳转方式难找的一逼极其让人无语。功能实现上也不咋样,但那是在数据库在后台就有的毛病了。

……为什么我要按着这个demo做呢。
可能一周前的我并不能意识到这些…为什么我当时没有找到一个质量特别棒的demo?
……要说现在我也不知道去哪找。

这一个星期我干了什么?把一部分html拆成vue-cli工程,然后把前后端搞通,新写了两三个觉得有必要的查询,从前后端到数据库,里面不喜欢看不懂的扔掉……现在就只剩五六个页面了。

我都觉得可以自己重新建工程写了…但感觉会好废时间……。

1 个赞

哈哈哈,有点拉跨,我看的血压上升了

过了好久我又想起来“跨域”这个词,还有在qq或者别的网站上点其他网页链接时弹出的提示。


嗯,这个就是跨域。也许从原本链接中点进外部链接,后一个网站后端能轻松拿到前一个网站发给前台的一些信息,为了安全,要阻止。
嗯,这是为什么需要限制跨域,那,是谁在限制跨域?嗯,浏览器干的。

而在前后端分离的项目开发中,有时候后端就要朝前端要浏览器里存的数据,不可避免的需要跨一下;这里开小道绕开浏览器的方式似乎也很多,但我看不懂不想看,我还是复制粘贴吧。

但就上面复制粘贴那个还是有点疑问…阻止跨域是浏览器替前端干的,为什么要、为什么可以在后端配置?不应该在前端写允许哪哪端口拿数据吗?这样看起来更多的是方便保护后端,不到处随意接数据啥的…

多级评论或者互相回帖的问题。
最简单的可能是在表里写个commentId和parentId然后直接相互@算球。
但常见的贴吧、b站、还会整个二级评论,在二级评论里面又是相互瞎胡@,估计也就是判断一下parentId是不是null的事。

然后我又突然突然看到了reddit,这里面的评论似乎是可以无限多级的…咋整的?
parentId肯定还是要,但这个里面拿到parentId不能只看是不是null,要用个while循环之类的东西把当前评论的一整串族谱给他扒出来存成个数组之类的东西。但是这个数组放哪合适,塞回数据库?总不能每回都算一遍吧。。
不对,从前台开始想。前台给出的评论是可以无限分级的,写了一层就提示可以有下一层,是递归,所以每一条评论都是要直接生成一个族谱数组的,parentId这个单个数字的方案可以直接丢掉。

这个估计和跨域没什么关系,应该仅仅是腾讯加的中间层,统计信息,打击竞争对手等作用吧

思考这个问题,就应该想一下,你在回复一个评论的时候,你真的在回复一个评论吗?


你看discourse的设计,里面附带的信息.
你只是发表了一个评论,另外引用了另一个评论和一个人而已.
想查询某两个人这个评论下的所有子回复,就好像哔哩哔哩的"查看所有对话",你猜怎么做.
很简单,与"parentId"一点关系都没有,只需要查询评论者和被引用者,按创建时间排个序,就完事了.

1 个赞

嗯,discourse回复的是人,不是具体的评论。QQ应该也是这样干的,原信息撤回但被回复里面还能看到。但这样是需要把上一个的那些文本再存一遍…对吧。。这样搞好处可能是快…嗯,肯定快。

但是如果像下面这种的,如果要弄二级还有更多级的评论,怎么判断一个评论该直接放在大的里面,还是放在一个评论的下面…这时候就必须加东西了吧。。。

(不知道具体的设计,应该类似链表吧,但是里面会加很多冗余字段

…是我傻了。就算是这样的多级结构,数据库里放的有单条评论的id和parent id这两个数字就够了。
结构关系可以在查询的时候整。

https://cn.bing.com/search?q=树与多级评论&

1 个赞