发表于: 2019-12-06 18:44:49
1 1318
完成了什么:看了一些深度思考,任务三总结和明天的例会总结一起写。
什么是代码生成,mybatis generator代码生成是怎么实现的,还有什么办法可以生成代码?
自动代码生成器根本原理就是根据实现写事先好的模板,再根据你提供的数据库结构,生成一系列的增删改查方法。 的确是可以减少程序员的工作量,但是不能包含复杂或者特殊的业务逻辑
MyBatis Generator(MBG)是MyBatis 和iBATIS的代码生成器。它将为所有版本的MyBatis以及版本2.2.0之后的iBATIS版本生成代码。 它将内省数据库表(或许多表),并将生成可用于访问表的工件。这减少了设置对象和配置文件以与数据库表交互的初始麻烦。 MBG寻求对简单CRUD(创建,检索,更新,删除)的大部分数据库操作产生重大影响
MYBATIS-GENERATOR怎么用?
1、建表
2、新建maven项目
3、配置依赖
4、写好generator配置文件
5、运行插件
还有什么办法可以生成代码?
GreedyStar/generator
什么是Sql注入,应该怎么解决?对于未做SQL注入防范的程序,你可以直接通过调用接口删掉表吗?
所谓SQL注入,就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令。
比如从登录模块来看,我们在将用户输入的条件在后台拼接成动态SQL查询时,如果用户按照我们设想的那样,用户名和密码都是正常的字符串,那么我们后台写的查询用户的语句:select * from user where user_name = '用户名' and password = '密码';便可以正常确认是否存在此用户的信息。
如果我们在用户名的输入框里输入的是:user ' or 1 = 1#的情况下,后台在执行这句SQL的时候,将将自动拼接成了select * from user where user_name = ‘user ' or 1 = 1#' and password = '密码'’`。而在mysql中,SQL语句中#后面的被当成注释了,而前面的查询中有一个恒成立的条件1=1 这就导致这条SQL语句查询的用户不是为空的,是存在的。此时便可以骗过服务器,模拟登陆成功的场景。
还有一种情况是在删除操作的时候,一般我们进行删除数据的时候,都是在url里拼接出要删除的数据的id什么的,delUserById.do?userId=1这时,在不怀好意的人获取到请求连接之后,在加上一个小小的or,比如这样:userId=2 or 1这样就有可能删除全部数据------sql注入就是通过类似的手段来破坏数据
如何避免sql注入呢?
1:遵循编程规范,首先执行预编译,随后再填写参数,这样参数会替换掉编译好的语句中的?占位符,最后执行完整的sql语句。
2:使用存储过程。
存储过程(Stored Procedure)是一组完成特定功能的SQL语句集,经编译后存储在数据库中,用户通过调用存储过程并给定参数(如果该存储过程带有参数)就可以执行它,也可以避免SQL注入攻击
3:mybatis半自动持久化框架,其底层原理也是预编译,参数替换占位符?
注意:
在编写MyBatis的映射语句时,尽量采用“#{xxx}”这样的格式。若不得不使用“${xxx}”这样的参数,要手工地做好过滤工作,来防止SQL注入攻击。
#{}:相当于JDBC中的PreparedStatement
${}:是输出变量的值
简单说,#{}是经过预编译的,是安全的;${}是未经过预编译的,仅仅是取变量的值,是非安全的,存在SQL注入。
为什么响应时间一般不允许超过200MS,怎么查看一个请求从发起到结束,耗费在什么地方了?
通常来说,人的眼睛对于200MS以上的时延是有反应的,所以一般而言,一整个页面都应该在200MS之内完成。 对于复杂的请求,可以再稍微慢一点,毕竟大家还能忍,能忍的程度跟网站的价值成正比。简单的用户个人信息这种请求,应该在50MS左右,List的数据,差不多在100MS左右。这是比较正常的数据。
对于一个网络请求来说,时间的损耗可以分解成三大部分。第一部分前端的响应,一般包括解析和渲染,这部分的性能跟前端的代码,前端硬件有关系。 第二部分就是网络延迟,这部分的代码正常来讲是在8~16MS左右,是的,Http请求就是差不多这个性能,如果是WebSocket几乎可以做到零延迟,第三部分就是服务器端的响应,我们说的是网站慢,一般而言,也就是主要在这里,要做性能优化的地方,基本上也是看这里。
什么是本地测试,什么是在开发环境测试?
一、开发环境:开发环境是程序猿们专门用于开发的服务器,配置可以比较随意, 为了开发调试方便,一般打开全部错误报告。通俗的讲,项目尚且在编码阶段,我们的代码一般在开发环境中,不会在生产环境中,生产环境组成:操作系统 ,web服务器 ,语言环境。
二、测试环境:一般是克隆一份生产环境的配置,一个程序在测试环境工作不正常,那么肯定不能把它发布到生产机上。通常指项目测试,修改bug阶段。
三、生产环境:是指正式提供对外服务的,一般会关掉错误报告,打开错误日志。可以理解为包含所有的功能的环境,任何项目所使用的环境都以这个为基础,然后根据客户的个性化需求来做调整或者修改。通俗的讲,项目数据前端后台已经跑通,部署在服务器上之后,有客户使用,访问,就是网站正式运行了。
三个环境也可以说是系统开发的三个阶段:开发->测试->上线,其中生产环境也就是通常说的真实环境。
为什么要先写单元测试?单元测试应该包括哪些?在正式打包的过程中,什么样的单元测试应该被屏蔽?在Maven里用什么方法可以跳过单元测试,单元测试应该被跳过吗。
单元测试的作用:
(1)让我们对自己的代码有信心
修改了代码后单测依然通过的,起码说明我们的修改没有破坏程序的正确性。这从主观上能增加我们对代码的信心。虽然单元测试通过了并不意味着程序就没有bug了,但我们也要了解到这可能不是单元测试的问题。单元测试顾名思义是测试一个”单元”,这个”单元”一般是类或方法,而不是整个系统。对整个系统的测试那是集成测试,功能测试的职责。单元测试追求的是快速反馈,频繁执行。集成测试虽然测“全局”,但成本较高,所以执行频率较少。两者使用场景不同,目的不同。
(2)为代码重构保驾护航
看到代码很差劲,想重构,但又担心重构之后出问题,怎么办呢?如果有单元测试情况就不一样了,重构完代码,跑一遍单元测试,如果单元测试都通过,基本上可以保证我们的重构没有破坏原来代码逻辑的正确性。不过前提是之前的写的单元测试质量很好,覆盖率很高。当然这仅限于小范围的重构,比如重构一个类或者函数的实现,但对于大刀阔斧的重构(比如单体重构成微服务,面向库表模式重构成DDD),就不适用,那个时候要重写单元测试了。
(3)通过单元测试快速熟悉代码
单元测试不仅起到了测试的作用,还是一种很好的“文档”,通过单元测试,我们不需要深入的阅读代码,便能知道这段代码做什么工作,有哪些特殊情况需要考虑,包含哪些业务。
哪些代码需要有单元测试覆盖:
1、逻辑复杂的
2、容易出错的
3、不易理解的,即使是自己过段时间也会遗忘的,看不懂自己的代码,单元测试代码有助于理解代码的功能和需求
4、公共代码。比如自定义的所有http请求都会经过的拦截器;工具类等。
5、 核心业务代码。一个产品里最核心最有业务价值的代码应该要有较高的单元测试覆盖率。
maven跳过单元测试的方法:
一:在命令中加上-Dmaven.test.skip=true
$ mvn install -Dmaven.test.skip=true
二:在pom.xml文件中配置maven-surefire-plugin插件
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
什么是实体表,什么是关系表,一对多和多对多应该怎么设计表?
(1)实体表就是对应实体对象的表,比如:学生表,老师表等,表里存放这他们各自的信息。
(2)关系表是表示表与表之间的数据关系,比如:每个学生表里的学生都对应着教师表里的一个或者多个教师,我们可以用另外的表存放他们之间的关系,当我们需要他们的某些信息时可以根据关系表里的关系查出来。
什么是一对一、一对多和多对多?
(1)一对一、一对多和多对多都是指数据表与表中的数据关系,而不是指表与表之间的关系。
(2)一对一:一个学生对应一个学生档案材料,或者每个人都有唯一的身份证编号。
(3)一对多:一个学生只属于一个班,但是一个班级有多名学生。
(4)多对多:一个学生可以选择多门课,一门课也可以对应着多名学生。
1.一对多关系处理:
比如一个班级对应多名学生,这时候我们可以在学生信息表里面加一个字段,用来表示学生对应的班级。
这里不建议通过添加主外键约束,因为这会让你以后在修改和删除表的时候很麻烦。
2.多对多关系处理:
通过学生选课了解多对多问题的处理:每个学生对应多门课,每门课对应多个学生。
(1)在多对多中在一个表中添加一个字段就行不通了,所以处理多对多表问题时,就要考虑建立关系表了。
(2)仅仅对应这里的举例而言,关系表中有三个字段,id,学生id,课程id
(3)根据学生查找课程:根据学生名字查询对应的多个课程。
(4)根据课程查找学生:根据课程名字查询对应的多个学生。
什么是外键,用处是什么,为什么不建议使用外键做关联?
如果公共关键字在一个关系中是主关键字,那么这个公共关键字被称为另一个关系的外键。
作用:保持数据一致性,完整性,主要目的是控制存储在外键表中的数据
外键适用于不经常变动的功能,但是现在网站和app的功能是不断更新迭代的,这就导致数据库结构可能发生变动
现在的设计原则是,将关系交给业务层来做,不要在数据库中加约束。
这样的好处是,一旦你的业务逻辑变了,不需要更改数据库结构,在业务代码里修改即可。
还有,如果你的数据库是分布式的,外键也不好用了。因为可能涉及到分库分表
遇到的问题:暂无
明天计划的事:开周会,任务总结
学到了什么:对任务理解更深了
评论