尚医通项目总结文档
[TOC]
表结构与实体类介绍
1. yygh_cmn
这个数据库就是数据字典部分的数据库,只有一个表那就是dict
数据表列 | 实体类参数 | ||
---|---|---|---|
id | 自增索引 | id | id |
parent_id | 所属类索引 | parentId | 上级id |
name | 名字 | name | 名字 |
value | 数字代码 | value | 数字代码(值) |
dict_code | 英文性介绍(部分) | dictCode | 编码 |
create_time | 创建时间 | createTime | 创建时间 |
update_time | 更新时间 | updateTime | 更新时间 |
is_deleted | 逻辑删除 | isDeleted | 逻辑删除 |
hasChildren | Boolean是否有子节点 | ||
param | hashmap 其他参数 |
dict表比较简单,其中
- @TableField 对应表column标题,对于表结构中没有的数据标为exist=false
- @TableLogic 逻辑删除
- 时间需要加@JsonFormat注解,来规定一下格式
2.yygh_hosp
该数据库也只有一个表 hospital_set对应实体类为model包下hosp中的hospitalSet
数据表列 | 实体类参数 | ||
---|---|---|---|
id | 自增索引 | id | id |
hosname | 医院名 | hosname | 医院名 |
hoscode | 医院编号 | hoscode | 医院编号 |
api_url | api链接 | api_url | api链接 |
sign_key | 签名秘钥 | sign_key | 签名秘钥 |
contacts_name | 联系人姓名 | contactsName | 联系人姓名 |
contacts_phone | 联系人电话 | contactsPhone | 联系人电话 |
status | 状态 | status | 状态 |
create_time | 创建时间 | createTime | 创建时间 |
update_time | 更新时间 | updateTime | 更新时间 |
is_deleted | 逻辑删除 | isDeleted | 逻辑删除 |
该表没有什么可说的
但中同样在hosp包中有一个新实体类为Hospital,该实体类无对应表,应该是在==逻辑部分==为了简洁显示而生出的新类。
参数 | 参数说明 |
---|---|
hoscode | 医院编号(唯一索引) |
hosname | 医院名 |
hostype | 医院类型(三甲乙) |
provinceCode | 省code |
cityCode | 城市code |
districtCode | 区code |
address | 地址 |
logoData | 医院logo |
intro | 医院简介 |
route | 坐车路线 |
status | 状态(是否上线) |
bookingRule | 预约规则 |
这个表中除了前三项之外,provinceCode 省code 、 cityCode 城市code、 districtCode 区code 、address 地址都是由dict查出来的。
其中bookingRule 预约规则也是延展出来的实体类
未完待续
3.yygh_manage
hospital_set 医院设置
- 该表与yygh_hosp中的表完全相同
order_info预定信息 对应实体类为OrderInfo
数据表 | 参数说明 | 实体类参数 | 解释 |
---|---|---|---|
hoscode | 医院编号(唯一索引) | hoscode | 医院编号(唯一索引) |
hosname | 医院名 | hosname | 医院名 |
hostype | 医院类型(三甲乙) | hostype | 医院类型(三甲乙) |
number | 预约号序 | number | 预约号序 |
depcode | 科室号 | depcode | 科室号 |
depname | 科室名称 | depname | 科室名称 |
schedule_id | 排版id | scheduleId | 排版id |
title | 医生主治领域 | title | 医生主治领域 |
reserve_date | 安排日期 | reserveDate | 安排日期 |
reserve_time | 安排时间 上下午 | reserveTime | 安排时间 上下午 |
patient_id | 就诊人id | patientId | 就诊人id |
patient_name | 就诊人名称 | patientName | 就诊人名称 |
patient_phone | 就诊人手机 | patientPhone | |
hos_record_id | 预约记录唯一标识(医院预约记录主键) | hosRecordId | 预约记录唯一标识(医院预约记录主键) |
fetch_time | 建议取号时间 | fetchTime | 建议取号时间 |
fetch_address | 取号地点 | fetchAddress | 取号地点 |
amout | 医事服务费 | amount | 医事服务费 |
quit_time | 退号时间 | quitTime | 退号时间 |
order_status | 订单状态 | orderStatus | 订单状态 |
对该表有巨大疑问特备是其中取号地点、退号状态、订单状态应该是与就诊人绑定表,每条数据对应一个就诊人,其中数据在业务逻辑中产生
schedule 排班表
该表对应的实体类就是Schedule
数据表 | 解释 | 备注 |
---|---|---|
id | 主键自增索引 | 实体类中没有 |
hoscode | 医院编号 | |
depcode | 科室编号 | |
title | 职称 | |
docname | 医生名称 | |
skill | 擅长技能 | |
workDate | 排班日期 | |
workTime | 排班时间 | 0:上午 1:下午 |
reservedNumber | 可预约数 | |
availableNumber | 剩余预约数 | |
amount | 挂号费 | |
status | 排班状态 | (-1:停诊 0:停约 1:可约) |
hosScheduleId | 排班编号 | 医院自己的排班主键 |
4.yygh_order
refund_info 退款信息表 对应的实体类是RefundInfo ,对应的是付款退款部分的业务逻辑
数据表 | 参数说明 | 实体类参数 | 解释 |
---|---|---|---|
id | 自增索引 | ||
out_trade_no | 对外业务编号 | outTradeNo | 对外业务编号 |
order_id | 订单编号 | orderId | 订单编号 |
payment_type | 支付类型 | paymentType | 支付类型(微信 支付宝) |
trade_no | 交易编号 | tradeNo | 交易编号 |
total_amount | 退款金额 | totalAmount | 退款金额 |
subject | 交易内容 | subject | 交易内容 |
refund_status | 退款状态 | refundStatus | 退款状态 |
callback_time | 回调时间 | callbackTime | 回调时间 |
callback_content | 调信息 | callbackContent | 回调信息 |
patment_info
该数据表对应的实体类为PaymentInfo
数据表 实体类 参数 | 解释 | 备注 |
---|---|---|
id | 自增索引 | 实体类无此项 |
outTradeNo | 对外业务编号 | |
orderId | 订单编号 | |
paymentType | 支付类型 | 微信 支付宝 |
tradeNo | 交易编号 | |
totalAmount | 支付金额 | |
subject | 交易内容 | |
paymentStatus | 支付状态 | |
callbackTime | 回调时间 | |
callbackContent | 回调信息 |
outTradeNo对外业务编号(订单交易号)作为一个重要参数联结了order_info、refund_info两个表
order_info
这是个比较复杂的表,该表几乎跑完user部分的整个业务逻辑
数据表 实体类 参数 | 解释 | 备注 |
---|---|---|
userId | userId | 联结userinfo表 |
outTradeNo | 订单交易号 | |
hoscode | 医院编号 | |
hosname | 医院名称 | 联结hospital_set表 |
depcode | 科室编号 | |
depname | 科室名称 | |
scheduleId | 排班id | |
title | 医生职称 | |
reserveDate | 安排日期 | |
reserveTime | 安排时间 | |
patientId | 就诊人id | |
patientName | 就诊人名称 | |
patientPhone | 就诊人手机 | |
hosRecordId | 预约记录唯一标识 | |
number | 预约号序 | |
fetchTime | 建议取号时间 | |
fetchAddress | 取号地点 | |
amount | 医事服务费 | |
quitTime | 退号时间 | |
orderStatus | 订单状态 |
5.yygh_user
patient
对应的实体是Patient
数据表 实体类 参数 | 解释 | 备注 |
---|---|---|
userId | 用户id | |
name | 姓名 | |
certificatesType | 证件类型 | |
certificatesNo | 证件编号 | |
sex | 性别 | |
birthdate | 出生年月 | |
phone | 手机 | |
isMarry | 是否结婚 | |
provinceCode | 省code | |
cityCode | 市code | |
districtCode | 区code | |
address | 详情地址 | |
contactsName | 联系人姓名 | |
contactsCertificatesType | 联系人证件类型 | string类型 |
contactsCertificatesNo | 联系人证件号 | |
contactsPhone | 联系人手机 | |
isInsure | 是否有医保 | |
cardNo | 就诊卡 | |
status | 状是态 | 是否认证 0 1 |
user_info
对应的是UserInfo
数据表 实体类 参数 | 解释 | 备注 |
---|---|---|
openid | 微信openid | |
nickName | 昵称 | |
phone | 手机号 | 是辨认的唯一主键 |
name | 用户姓名 | |
certificatesType | 证件类型 | |
certificatesNo | 证件编号 | |
certificatesUrl | 证件路径 | |
authStatus | 认证状态 | 0:未认证 1:认证中 2:认证成功 -1:认证失败 |
status | 状态 | 0:锁定 1:正常 |
user_login_record
对应实体类UserLoginRecord用户登录日志,这个是一个辅助性的记录表,记录用户的登录ip,用的user_id做联结
数据表 实体类 参数 | 解释 | 备注 |
---|---|---|
userId | 用户id | |
ip | 登录ip |
微服务模块业务逻辑
后端管理平台业务逻辑
1、医院设置管理
这一部分所属模块就是service_hosp模块
(1)医院设置列表、添加、锁定、删除
这个类下的所有方法都是通过三层架构对数据表hospital_set进行 操作,所以实体类也指hospital_set
controller层方法:
- 查询医院设置表所有信息
- 调list方法
- 逻辑删除医院设置
- 调removebyid方法
- 条件查询带分页(当前页、每页记录数、实体类)
- 构建querywarpper,可以是医院名或医院编码
- 调用page方法传入分页数和查询条件
- 添加医院设置(实体类hospitalset)
- 对新对象生成签名密匙校对,调用
hospitalSet.setSignKey
,该方***调用MD5进行加密 hospitalSetService.save
进行保存
- 对新对象生成签名密匙校对,调用
- 根据id获取医院设置 id
hospitalSetService.getById
查询
- 修改医院设置hospitalSet
hospitalSetService.updateById
修改,该方法传的是实体类
- 批量删除 同上删除
- hospitalSetService.removeByIds(idList)
- 医院设置锁定和解锁
- 通过id查询得到实体类
- 实体类中设置状态
- 上传实体类更新表
- 发送签名秘钥
(2)医院列表、详情、下线
HospitalController下面的所有方法都调用hospitalService接口,该接口的业务是比较复杂的,应当重点重视
医院列表(条件查询分页)
- 分页查询方法
hospitalService.selectHospPage(page,limit,hospitalQueryVo)
- 在service中该方法先将hospitalQueryVo赋值给hospital,再调hospitalRepository将hospital数据补充完整。
- 详见下表格对比hospital与hospitalQueryVo
参数前者 参数说明 后者 hoscode 医院编号(唯一索引) hosname 医院名 hostype 医院类型(三甲乙) provinceCode 省code cityCode 城市code districtCode 区code address 地址 无 logoData 医院logo 无 intro 医院简介 无 route 坐车路线 无 status 状态(是否上线) 有 bookingRule 预约规则 无 这些没有的内容都存在MongoDB中,所以这个创造出了新实体类,调用hospitalRepository也说得通了
- 分页查询方法
更新医院上线状态id status
- 先查询
hospitalRepository.findById(id)
- 再修改
hospital.setStatus(status)
- 最后保存
hospitalRepository.save(hospital)
- 先查询
医院详情信息
- 传给map,hospitalService.getHospById(id)
- 通过id调repository查询
(3)排班接口
效果图:
排班分成三部分显示:
1、科室信息(大科室与小科室树形展示)
2、排班日期,分页显示,根据上传排班数据聚合统计产生
3、排班日期对应的就诊医生信息
接口分析:
科室数据使用Element-ui el-tree组件渲染展示,需要将医院上传的科室数据封装成两层父子级数据;
聚合所有排班数据,按日期分页展示,并统计号源数据展示;
根据排班日期获取排班详情数据
实现分析:
虽然是一个页面展示所有内容,但是页面相对复杂,我们分步骤实现
先实现左侧科室树形展示;
其次排班日期分页展示
最后根据排班日期获取排班详情数据
(1) 左侧科室的树形展示
该接口写在DepartmentController类中
controller层:
- 根据医院编号,查询医院所有科室列表findDeptTree方法,传入的是医院码
- 调用该方法
departmentRepository.findAll
查出所有科室,同时大科室下还有可能有小科室 - 循环所有大科室,如果里面还有小科室那么可以查出来放到大科数组中
- 调用该方法
(2) 排班日期分页展示
该接口写在ScheduleController中
controller层:
- 查询排班规则数据getScheduleRule
- 在service层中实现这个方法getRuleSchedule
(3)排班日期获取排班详情
查询排班详;细信息**getScheduleDetail**
controller:
- getScheduleDetail获取排班详情,传的有医院名、医院码、工作时间
- 直接在service中查出来再遍历返回
2、数据管理
(1)数据字典树形显示、导入、导出
效果图:
该板块所有接口都写在DictController类中
- 显示方法 实际上是由三个查询方法构成的:
- 根据数据id查询子数据列表findChlidData
- 写querywrapper
- 调basemapper查询
- 判断下面是否有子节点isChildren
- 根据父节点id获取子节点数据列表findByParentId
树形结构的导入、导出
导入数据字典importDictData(MultipartFile file)
- 直接掉easyexcle的EasyExcel.read方法即可
导出数据字典exportDict(HttpServletResponse response)
- 先做设置:文件类型setContentType、setCharacterEncoding编码、fileName文件名、setHeader响应头
- 查询数据库,将数据写到上面那个file中,最后返回
3、用户管理
(1)用户列表、查看、锁定
controller层
- 用户列表(条件查询带分页)list
- 先定义Page<userinfo>,这里需要当前页、每页记录数两个参数</userinfo>
- 调userInfoService.selectPage方法
- 用户详情show
- 直接把id传进去,得到的是map,userInfoService.show(userId)
- 通过service的另一个方法this.packageUserInfo把用户信息查出来
- 这个方***验证状态码 看其是否正常的
- 再调用patientService.findAllUserId查询该用户的就诊人信息
- 用户锁定lock
- 调userInfoService.lock
- service中 先进行查询,selectById
- 再修改status->setStatus
(2)认证用户审批
- 认证审批approval(userId,authStatus)
- authStatus =-1 或2
- 再baseMapper.selectById查询
- 把状态码setAuthStatus放进去
4、订单管理
(1)订单列表、详情
下单参数:就诊人id与排班id
下单我们要获取就诊人信息
获取排班下单信息与规则信息
获取医院签名信息,然后通过接口去医院预约下单
下单成功更新排班信息
这里对外暴露的接口有订单列表、根据订单id查询订单详情两个
- 订单列表(条件查询带分页)list
- 调orderService.selectPage得到订单
- 先对orderQueryVo获取条件值,比如医院名称、就诊人之类的
- 对条件值进行非空判断
- 调用mapper的方法进行订单的查询
- 遍历封装
- 根据订单id查询订单详情getOrders(id)
- 调用方法orderService.getOrder
- 调mapper查询
user前台系统业务逻辑
对于前台系统,所有的方法命名包裹放在api·中
1、首页数据显示
(1)医院列表
作为首页数据显示的api接口,url是/api/hosp/hospital
controller层:
- index方法
- 调用hospitalService.selectHospPage
- 写warpper,调hospitalRepository.findAll
- 返回
2、医院详情显示
(1)医院科室显示
该方法是获取科室获取科室列表url是department/{hoscode}
- index
- 直接调用之前用过的departmentService.findTree(hoscode)
3、用户实名认证
该方法可以看做是user用户信息的一个完善
- userAuth 传递两个参数,第一个参数用户id,第二个参数认证数据vo对象
- 调用同名方法
- 补充一起其他登记信息,在调basemapper 的存储
4、就诊人管理
(1)列表、添加、根据id查询、修改、详情、删除
这些方法在user包的PatientApiController类中
- 用户列表findAll一个简单的查询
- 添加就诊人savePatient
- 根据就诊人id获取就诊人信息
- 直接调service层patientService.getPatientId方法
- 修改就诊人
- 根据就诊人id获取就诊人信息
- patientService.getPatientId
- service方法 写warpper,然后直接调basemapper.select
- 删除就诊人
- patientService.removeById(id)
5、预约挂号功能
(1)挂号详情信息
- 获取医院预约挂号详情item
- service层调用方法hospitalService.item(hoscode),要传入医院编号
- 先调用this.setHospitalHosType
- 该方法返回的是一个包含项数比较多的方法
- new一个map,然后把hospital和bookingRule放进去
(2)生成挂号信息
此处是order.api中的OrderApiController的saveOrder方法。url是auth/submitOrder/{scheduleId}/{patientId}
生成挂号订单的逻辑比较复杂,这里改下格式,编号代表逻辑,字母代表方法
- 获取就诊人信息
- patientFeignClient.getPatientOrder
- 获取排班相关信息
- hospitalFeignClient.getScheduleOrderVo(scheduleId)
- 判断当前时间是否还可以预约
- 过了上午就不能约上午了
- 获取签名信息
- 签名信息中包含了医院的apiurl访问路径,从这里可以访问到医院的那个接口这样医院才能让医院同意
- hospitalFeignClient.getSignInfoVo,这里获得你想挂的那个医院的api然后后面才能提交
- 添加到订单表
- 这里要把patient里面多的数据都摘出来放入order实体类中
- 调用baseMapper插入
- 调用医院接口,实现预约挂号操作
- 先要补充完善数据
(3)查询挂号订单
该方法在order板块的OrderApiController类中
路径为/api/order/orderInfo
- 订单列表(条件查询带分页)list
- 一个简单的select方法
(4)取消预约挂号
- 取消预约cancelOrder
- 首先查到订单
- 判断是否取消
- 删除预约的订单
6、下单与支付
下单我们要获取就诊人信息
获取排班下单信息与规则信息
获取医院签名信息,然后通过接口去医院预约下单
下单成功更新排班信息与发送短信
7、就医提醒功能
微服务支持模块业务逻辑
这一部分主要讲解几个辅助性模快,他们的重点不是业务逻辑,而是配置和原理
阿里云短信服务模块
1.申请阿里云短信服务
申请地址为阿里云上的短信服务
- 由于私人无法申请,故无法使用这一部分
- 这里假设已经申请成功
2.相关配置
aliyun.sms.regionId=公网访问地址 aliyun.sms.accessKeyId=id aliyun.sms.secret=密匙
这些内容为application中的配置
3.controller逻辑
- 从redisTemplate里获取验证码,redis里的验证码有时间限制,他会过期
- 如果没有就现生成一个code
- 调用service的发送方法
4.service逻辑
这里主要就是一个功能,保证验证码的成功发送,而且验证码已经从controller层给出来了
- 判断手机是不是空的,如空就报错
- 设置阿里云的一堆参数(直接取即可)
- new 一个CommonRequest,将手机号、签名、code都放进去
- 调用发送方法
阿里云OSS服务模块
用户认证需要上传证件图片、首页轮播也需要上传图片,因此我们要做文件服务,阿里云oss是一个很好的分布式文件服务系统,所以我们只需要集成阿里云oss即可
1.阿里云OSS的开通和操作
这个网上的教程比较多
(1)申请阿里云账号
(2)实名认证
(3)开通“对象存储OSS”服务
(4)进入管理控制台
(5)阅读java SDK操作手册,进行配置
2.配置和具体逻辑
aliyun.oss.endpoint=oss-cn-杭州.aliyuncs.com aliyun.oss.accessKeyId=id aliyun.oss.secret=密匙 aliyun.oss.bucket=yygh-atguigu 这个bucket名
controller层:
- 只有一个方法,那就是上传文件
service层:
实现上传方法
- 获取配置参数
- uuid生成文件名
- 打开ossClient,实现上传方法
- 关闭ossclient并返回url
返回的url比较特殊,是String url = "https://"+bucketName+"."+endpoint+"/"+fileName;
其中bucketname就是bucket名,endpoint是公网访问地址,filename是文件名
jwt令牌模块
JWT(Json Web Token)是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准。
JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源。比如用在用户登录上
JWT最重要的作用就是对 token信息的防伪作用。
一个JWT由三个部分组成:公共部分、私有部分、签名部分。最后由这三者组合进行base64编码得到JWT。
base64编码,并不是加密,只是把明文信息变成了不可见的字符串。但是其实只要用一些工具就可以把base64编码解成明文,所以不要在JWT中放入涉及私密的信息
比较重要的是jwthelp类,这里全贴上来,以厘清逻辑
public class JwtHelper { //过期时间 private static long tokenExpiration = 24*60*60*1000; //签名秘钥 private static String tokenSignKey = "123456"; //根据参数生成token public static String createToken(Long userId, String userName) { String token = Jwts.builder() .setSubject("YYGH-USER") .setExpiration(new Date(System.currentTimeMillis() + tokenExpiration)) .claim("userId", userId) .claim("userName", userName) .signWith(SignatureAlgorithm.HS512, tokenSignKey) .compressWith(CompressionCodecs.GZIP) .compact(); return token; } //根据token字符串得到用户id public static Long getUserId(String token) { if(StringUtils.isEmpty(token)) return null; Jws<Claims> claimsJws = Jwts.parser().setSigningKey(tokenSignKey).parseClaimsJws(token); Claims claims = claimsJws.getBody(); Integer userId = (Integer)claims.get("userId"); return userId.longValue(); } //根据token字符串得到用户名称 public static String getUserName(String token) { if(StringUtils.isEmpty(token)) return ""; Jws<Claims> claimsJws = Jwts.parser().setSigningKey(tokenSignKey).parseClaimsJws(token); Claims claims = claimsJws.getBody(); return (String)claims.get("userName"); } public static void main(String[] args) { String token = JwtHelper.createToken(1L, "lucy"); System.out.println(token); System.out.println(JwtHelper.getUserId(token)); System.out.println(JwtHelper.getUserName(token)); } }
gateway模块
1.gateway介绍
Spring cloud gateway是spring官方基于Spring 5.0、Spring Boot2.0和Project Reactor等技术开发的网关,Spring Cloud Gateway旨在为微服务架构提供简单、有效和统一的API路由管理方式,Spring Cloud Gateway作为Spring Cloud生态系统中的网关,目标是替代Netflix Zuul,其不仅提供统一的路由方式,并且还基于Filer链的方式提供了网关基本的功能,例如:安全、监控/埋点、限流等
2.为什么需要网关
(1)客户端会多次请求不同的微服务,增加了客户端的复杂性。
(2)存在跨域请求,在一定场景下处理相对复杂。
(3)认证复杂,每个服务都需要独立认证。
(4)难以重构,随着项目的迭代,可能需要重新划分微服务。例如,可能将多个服务合并成一个或者将一个服务拆分成多个。如果客户端直接与微服务通信,那么重构将会很难实施。
(5)某些微服务可能使用了*** / 浏览器不友好的协议,直接访问会有一定的困难。
以上这些问题可以借助 API 网关解决。API 网关是介于客户端和服务器端之间的中间层,所有的外部请求都会先经过API 网关这一层。也就是说,API 的实现方面更多的考虑业务逻辑,而安全、性能、监控可以交由 API 网关来做,这样既提高业务灵活性又不缺安全性
3.如何启动与配置
主要是需要在gateway模块的application中进行配置
# 服务端口 server.port=80 # 服务名 spring.application.name=service-gateway # nacos服务地址 spring.cloud.nacos.discovery.server-addr=127.0.0.1:8848 #使用服务发现路由 spring.cloud.gateway.discovery.locator.enabled=true #设置路由id spring.cloud.gateway.routes[0].id=service-hosp #设置路由的uri spring.cloud.gateway.routes[0].uri=lb://service-hosp #设置路由断言,代理servicerId为auth-service的/auth/路径 spring.cloud.gateway.routes[0].predicates= Path=/*/hosp/** #设置路由id spring.cloud.gateway.routes[1].id=service-cmn #设置路由的uri spring.cloud.gateway.routes[1].uri=lb://service-cmn #设置路由断言,代理servicerId为auth-service的/auth/路径 spring.cloud.gateway.routes[1].predicates= Path=/*/cmn/**
这里配置了所有需要微服务的网关
- spring.application.name服务名一定要和微服务对应
- nacos也是必要的
Feign技术
微服务之间调用的一个关键技术
前端技术点
虽然前端技术不是重点,但我们也需要进行了解。
如何启动这个项目——>npm的使用
一、安装配置Node和前言
# 查看 npm 的版本 $ npm -v //6.4.0 << 安装成功会返回版本号 # 查看各个命令的简单用法 $ npm -l # 查看 npm 命令列表 $ npm help # 查看 npm 的配置 $ npm config list -l
二、npm init 创建模块
$ npm init
npm init
用来初始化生成一个新的package.json
文件。它会向用户提问一系列问题,如果觉得不用修改默认配置,一路回车就可以了。
三、npm list 查看模块
#当前项目安装的所有模块 $npm list #列出全局安装的模块 带上[--depth 0] 不深入到包的支点 更简洁 $ npm list -g --depth 0
四、npm install 安装模块
基本用法
# 读取package.json里面的配置单安装 $ npm install //可简写成 npm i # 默认安装指定模块的最新(@latest)版本 $ npm install [<@scope>/]<name> //eg:npm install gulp # 安装指定模块的指定版本 $ npm install [<@scope>/]<name>@<version> //eg: npm install gulp@3.9.1 # 安装指定指定版本范围内的模块 $ npm install [<@scope>/]<name>@<version range> //eg: npm install vue@">=1.0.28 < 2.0.0" # 安装指定模块的指定标签 默认值为(@latest) $ npm install [<@scope>/]<name>@<tag> //eg:npm install sax@0.1.1 # 通过Github代码库地址安装 $ npm install <tarball url> //eg:npm install git://github.com/package/path.git
配置选项说明:
#全局安装 -g | -global //eg: npm i -g gulp 或者 npm i gulp -g #这是默认设置,除非-D或-O存在 #安装并将被添加到package.json的dependencies区。 -P | --save-prod #(生产阶段的依赖) #安装并将被添加到package.json的dependencies区 -S | --save //eg: npm i gulp --save 或 npm i gulp -S #(开发阶段的依赖) #安装并将被添加到package.json的devDependencies区。 -D | --save-dev //npm i gulp --save-dev 或 npm i gulp -D #(可选阶段的依赖) #安装并将被添加到package.json的optionalDependencies区 -O | --save-optional #安装模块的确切版,而不是使用npm的默认semver range运算符 -E | --save-exact //npm i gulp --save-exact 或 npm i gulp -E #安装并将被添加到
bundleDependencies
列表中 -B | --save-bundle #模块不管是否安装过,npm 都要强制重新安装 -f|--force //eg:npm install sax --force //补充:所有模块都要强制重新安装,那就删除node_modules
,重新执行npm install
npm install #防止保存到dependencies
--no-save #报告安装状况而不是真的安装 --dry-run
五、npm uninstall 卸载模块
#卸载当前项目或全局模块 $ npm uninstall <name> [-g] eg: npm uninstall gulp --save-dev npm i gulp -g 卸载后,你可以到 /node\_modules/ 目录下查看包是否还存在,或者使用以下命令查看: npm ls 查看安装的模块
六、npm update 更新模块
#升级当前项目或全局的指定模块 $ npm update <name> [-g] //eg: npm update express npm update express -g
七、npm run 执行脚本
package.json
的scripts
字段,可以用于指定脚本命令,供npm
直接调用。npm run
会创建一个Shell,执行指定的命令。
npm run
的参数。
- 如果不加任何参数,直接运行,会列出
package.json
里面所有可以执行的脚本命令
如何接上前后端——>配路由
前后端在解决了跨域之后,联结是非常简单的,这里写一个简单的api
import request from '@/utils/request' const api_name = `/api/msm` export default { sendCode(mobile) { return request({ url: `${api_name}/send/${mobile}`, method: `get` }) } }
- 这里api_name就是后端那个conroller整个类的api路径
- 方法体中的url 就是方法的URL路径
- method:代表是个get方法
Vue、elemt-ui、nuxt 的了解
双向绑定、组件化
Vue结构:
1.
这里主要放各类样式信息,比如从element-ui里摘出来的东西
如下例:
<template> <div class="app-container"> 医院设置添加 <el-form label-width="120px"> <el-form-item label="医院名称"> <el-input v-model="hospitalSet.hosname"/> </el-form-item> </el-form> </div> </template>
这是一个表格结构
2.