|
|
// 引入Express框架的核心模块，用于创建Web应用、定义路由以及处理HTTP请求等相关操作。
|
|
|
// Express是基于Node.js平台构建Web应用的常用框架，它提供了便捷的方式来搭建服务器、配置路由以及处理诸如GET、POST、PUT、DELETE等不同类型的HTTP请求，
|
|
|
// 让开发者能够高效地构建后端服务，实现前后端的数据交互和业务逻辑处理。
|
|
|
var express = require('express');
|
|
|
|
|
|
// 创建一个Express路由器实例，方便以模块化的方式来定义一组相关的路由，便于在整个应用中进行有条理的路由管理。
|
|
|
// 使用路由器实例可以将不同功能模块对应的路由进行分类组织，比如可以把用户管理相关路由放在一个路由器实例中，订单管理相关路由放在另一个实例里，
|
|
|
// 这样使得整个应用的路由结构更加清晰，易于维护和扩展，避免所有路由定义都混杂在一起导致代码可读性差和维护困难。
|
|
|
var router = express.Router();
|
|
|
|
|
|
// 引入Node.js的path模块，主要用于处理文件路径相关的操作，例如拼接、解析文件路径等，以便准确地引入其他模块。
|
|
|
// 在Node.js项目中，模块的位置是通过文件路径来指定的，path模块提供了实用的方法来处理这些路径。例如，path.join可以将多个路径片段正确拼接成一个完整路径，
|
|
|
// 确保无论项目在何种环境下运行，都能准确地找到并加载所需的模块，这对于组织项目结构和模块间的引用非常重要。
|
|
|
var path = require("path");
|
|
|
|
|
|
// 获取自定义的验证模块，通过path.join方法将当前工作目录（process.cwd()）与相对路径（"/modules/authorization"）拼接起来，准确地引入该验证模块。
|
|
|
// 这种动态拼接路径的方式能够适应不同部署环境下项目目录结构的变化，保证能精准地定位到验证模块所在位置。
|
|
|
// 该验证模块在整个应用的安全架构中起着关键作用，通常用于验证用户的权限等情况，比如判断用户是否有访问某个资源或者执行某个操作的权限，
|
|
|
// 以此确保后续所有的操作都严格遵循相应的安全和业务规则，防止出现越权访问、非法操作等情况，保障系统的数据安全和业务流程的正常运行。
|
|
|
var authorization = require(path.join(process.cwd(), "/modules/authorization"));
|
|
|
|
|
|
// 通过验证模块获取名为"ManagerService"的用户管理服务对象，该模块应该封装了与用户相关的各种业务操作方法，例如用户的增删改查、角色分配以及状态更新等功能。
|
|
|
// 将用户管理相关的复杂业务逻辑封装在这个服务对象内部，使得代码的职责划分更加清晰。在路由处理函数中，只需调用该服务对象提供的对应方法即可完成具体的业务操作，
|
|
|
// 而不用把大量的业务逻辑代码（如数据库查询、更新操作，权限判断逻辑等）都写在路由函数里，这样既方便代码的复用，也让路由代码更加简洁、易读，专注于处理请求和响应相关的逻辑。
|
|
|
var mgrServ = authorization.getService("ManagerService");
|
|
|
|
|
|
// 定义处理查询用户列表的GET请求的路由，路径为根路径 "/"。
|
|
|
// 这意味着当客户端向服务器发送GET请求到根路径时，服务器会依据此路由定义来处理该请求，主要目的是从数据库或其他数据源中获取满足一定条件的用户列表信息，
|
|
|
// 并将获取到的信息返回给客户端，例如在前端页面展示用户列表等应用场景会触发这样的请求。
|
|
|
router.get("/",
|
|
|
// 第一个中间件函数，用于对请求中的查询参数进行验证，确保传入的参数符合业务要求，保证后续业务逻辑能正确执行。
|
|
|
// 在查询用户列表的业务场景中，通常会有一些必要的查询参数，如分页相关的参数（用于控制显示哪些页的数据），这里需要对这些参数进行合法性检查，
|
|
|
// 避免因参数错误导致后续的数据库查询等业务操作出现异常，例如查询出不符合预期的数据或者直接导致查询失败等情况。
|
|
|
function (req, res, next) {
|
|
|
// 验证pagenum参数是否存在且大于0，如果该参数不存在或者小于等于0，则返回错误响应，状态码400表示请求参数有误，并附带相应的错误提示信息"pagenum 参数错误"。
|
|
|
// pagenum参数一般用于表示当前请求要获取的是第几页的用户列表数据，在分页查询逻辑中，它必须是一个大于0的有效数值，若不存在或不符合要求，
|
|
|
// 服务器就无法准确确定要返回哪一页的数据，所以需要进行验证并及时返回错误提示给客户端，让客户端修正参数后重新发起请求。
|
|
|
if (!req.query.pagenum || req.query.pagenum <= 0) return res.sendResult(null, 400, "pagenum 参数错误");
|
|
|
// 验证pagesize参数是否存在且大于0，如果该参数不存在或者小于等于0，则返回错误响应，状态码400表示请求参数有误，并附带相应的错误提示信息"pagesize 参数错误"。
|
|
|
// pagesize参数通常用来指定每页显示多少条用户记录，同样需要保证其合法性，若该参数缺失或小于等于0，就无法按照正确的分页逻辑查询和返回数据，
|
|
|
// 所以也要进行验证并在参数不符合要求时返回相应的错误信息给客户端。
|
|
|
if (!req.query.pagesize || req.query.pagesize <= 0) return res.sendResult(null, 400, "pagesize 参数错误");
|
|
|
// 参数验证通过后，调用next()函数将控制权传递给下一个中间件或者路由处理函数，以便继续执行后续的业务逻辑。
|
|
|
// 在Express框架的中间件机制中，next()函数起着关键的流程控制作用，它使得请求能够按照定义的顺序依次经过各个中间件进行相应的处理，
|
|
|
// 如果不调用next()，请求将会阻塞在当前中间件，无法继续往后执行其他中间件或路由处理函数中的逻辑。
|
|
|
next();
|
|
|
},
|
|
|
// 第二个中间件函数，用于处理查询用户列表的实际业务逻辑，依赖于前面验证通过的参数进行相应操作。
|
|
|
// 在前面的参数验证中间件通过后，请求会流转到这个中间件来执行具体的查询用户列表操作，比如根据传入的分页参数（pagenum和pagesize）以及可能的模糊查询内容（query），
|
|
|
// 去数据库中构建合适的查询语句，执行查询操作以获取符合条件的用户记录，然后对查询到的数据进行整理、格式化等处理，最终将合适的用户列表数据返回给客户端。
|
|
|
function (req, res, next) {
|
|
|
// 调用mgrServ用户管理服务对象的getAllManagers方法，传入一个包含查询条件的对象，其中包括模糊查询的内容（query）以及分页相关的参数（pagenum和pagesize），用于获取符合条件的用户列表数据。
|
|
|
// getAllManagers方法是在ManagerService模块中定义的一个用于查询用户列表的方法，它接收包含查询条件的对象作为参数，在内部会与数据库等数据存储进行交互，
|
|
|
// 通过执行相应的查询语句（可能涉及到SQL语句的构建、数据库连接等操作）来获取满足条件的用户记录集合，由于这是一个涉及到数据库操作等可能耗时的异步操作，
|
|
|
// 所以需要通过回调函数来处理操作完成后的结果情况，根据操作成功与否返回相应的响应给客户端。
|
|
|
mgrServ.getAllManagers(
|
|
|
{
|
|
|
"query": req.query.query,
|
|
|
"pagenum": req.query.pagenum,
|
|
|
"pagesize": req.query.pagesize
|
|
|
},
|
|
|
function (err, result) {
|
|
|
// 如果在获取用户列表的操作过程中出现错误（err不为null），比如数据库查询出现语法错误、连接失败或者权限不足无法访问相关数据等情况，
|
|
|
// 就通过res.sendResult返回包含错误信息的响应，状态码设置为400，表示请求处理出现错误，同时将具体的错误信息（err）传递给客户端，
|
|
|
// 让客户端知晓请求失败的原因，以便客户端根据错误提示进行相应的处理，例如检查网络连接、修正请求参数等。
|
|
|
if (err) return res.sendResult(null, 400, err);
|
|
|
// 如果获取用户列表操作成功，就使用res.sendResult返回包含用户列表数据（result）的响应，状态码为200，表示请求成功，同时附带提示信息"获取管理员列表成功"，
|
|
|
// 告知客户端操作顺利完成，客户端接收到返回的用户列表数据后，可以根据业务需求进行相应的处理，比如在前端页面上展示用户列表、进行进一步的筛选操作等。
|
|
|
res.sendResult(result, 200, "获取管理员列表成功");
|
|
|
}
|
|
|
)(req, res, next);
|
|
|
|
|
|
}
|
|
|
);
|
|
|
|
|
|
// 定义处理获取用户信息的GET请求的路由，路径中包含用户ID参数，格式为 "/:id"。
|
|
|
// 当客户端向服务器发送GET请求并且在请求路径中携带了具体的用户ID时，服务器会依据此路由定义来处理该请求，目的是获取对应ID的用户的详细信息，
|
|
|
// 例如用户的基本资料（用户名、手机号、邮箱等）、关联的角色信息、账户状态等详细内容，并将这些信息返回给客户端，常用于用户详情页面的展示等场景。
|
|
|
router.get("/:id",
|
|
|
// 第一个中间件函数，主要用于对路由参数进行验证，确保传入的用户ID参数符合业务要求，保证后续业务逻辑能正确执行。
|
|
|
// 因为要准确获取特定用户的详细信息，首先必须确保传入的用户ID是合法有效的，否则无法在数据库或其他数据源中准确找到对应的用户记录进行后续操作，
|
|
|
// 所以需要对用户ID参数进行严格的验证，防止因参数错误导致查询失败或者获取到错误的用户信息等情况发生。
|
|
|
function (req, res, next) {
|
|
|
// 检查请求参数中的用户ID（req.params.id）是否存在，如果不存在则返回错误响应，状态码400表示请求参数有误，同时附带提示信息"用户ID不能为空"。
|
|
|
// 用户ID是用于唯一标识每个用户的关键信息，在获取用户详细信息的请求中，如果没有提供该参数，服务器就不知道要获取哪个用户的详细信息，
|
|
|
// 所以必须要求该参数存在，若不存在则直接返回错误提示给客户端，要求其补充正确的参数后重新发起请求。
|
|
|
if (!req.params.id) {
|
|
|
return res.sendResult(null, 400, "用户ID不能为空");
|
|
|
}
|
|
|
// 进一步验证用户ID是否可以转换为数字类型，如果不能转换成功（即不是有效的数字），则返回错误响应，状态码同样为400，并附带提示信息"用户ID必须是数字"。
|
|
|
// 在通常的系统设计中，用户ID在数据库等存储介质中是以数字形式进行存储和标识的，所以传入的用户ID参数需要能够正确转换为数字类型，
|
|
|
// 这样才能准确地与数据库中的记录进行匹配，进行后续的查询操作，若参数不符合要求则返回相应的错误信息给客户端。
|
|
|
if (isNaN(parseInt(req.params.id))) return res.sendResult(null, 400, "用户ID必须是数字");
|
|
|
// 如果参数验证通过，就调用next()函数，将控制权传递给下一个中间件或者路由处理函数，以便继续执行后续的业务逻辑。
|
|
|
// 通过调用next()，遵循Express中间件的执行流程，使得请求能够继续流转到下一个中间件或路由处理函数中，去执行获取用户详细信息的具体业务逻辑。
|
|
|
next();
|
|
|
},
|
|
|
// 第二个中间件函数，用于处理获取指定用户信息的实际业务逻辑，依赖于前面验证通过的用户ID参数进行相应操作。
|
|
|
// 在前面的参数验证中间件通过后，请求会进入这个中间件来执行具体的获取指定用户详细信息的操作，比如根据传入的用户ID去数据库中查询对应的用户记录，
|
|
|
// 提取出该用户的各项详细信息（如用户名、密码、角色、状态等），然后将这些详细信息整理成合适的数据格式返回给客户端，以便客户端进行展示或其他相关操作。
|
|
|
function (req, res, next) {
|
|
|
// 调用mgrServ用户管理服务对象的getManager方法，传入经过验证的用户ID（req.params.id），用于获取该用户的详细信息。
|
|
|
// getManager方法是在ManagerService模块中定义的用于根据给定的用户ID从数据库等数据存储中查找并获取对应用户详细信息的方法，
|
|
|
// 它会与数据库进行交互，执行相应的查询语句（可能涉及到关联查询等操作，取决于用户信息与其他数据表的关联关系）来获取用户的详细记录，
|
|
|
// 由于这是一个异步操作，同样需要通过回调函数来处理操作完成后的结果情况，根据查询结果成功与否返回相应的响应给客户端。
|
|
|
mgrServ.getManager(req.params.id, function (err, manager) {
|
|
|
// 如果在获取用户信息的操作过程中出现错误（err不为null），例如数据库查询失败（可能是用户ID对应的记录不存在、数据库连接问题等原因），
|
|
|
// 就通过res.sendResult返回包含错误信息的响应，状态码设置为400，表示请求处理出现错误，同时将具体的错误信息（err）传递给客户端，
|
|
|
// 让客户端知晓获取用户信息失败的原因，以便采取相应的措施，比如检查用户ID是否正确等。
|
|
|
if (err) return res.sendResult(null, 400, err);
|
|
|
// 如果获取用户信息操作成功，就使用res.sendResult返回包含用户详细信息（manager）的响应，状态码为200，表示请求成功，同时附带提示信息"获取成功"，
|
|
|
// 告知客户端操作顺利完成，客户端接收到返回的用户详细信息后，可以根据业务需求进行展示、编辑（如果有相应权限）等后续操作。
|
|
|
res.sendResult(manager, 200, "获取成功");
|
|
|
})(req, res, next);
|
|
|
}
|
|
|
);
|
|
|
//这段代码主要围绕用户管理模块中查询用户列表和获取单个用户信息这两个功能，通过定义相应的路由及
|
|
|
//配套的中间件函数，实现了对请求参数的严格验证以及基于验证通过的参数进行具体的业务逻辑处理（从
|
|
|
//数据源获取用户相关数据并返回给客户端），保障了用户管理相关功能在请求处理方面的准确性和合法性。
|
|
|
// 定义处理创建用户的POST请求的路由，路径为 "/"。
|
|
|
// 意味着当客户端向服务器发送POST请求到根路径时，服务器会依据此路由配置来处理该请求，该请求主要用于创建新的用户。
|
|
|
// 在实际应用中，客户端需要在请求体中提供创建用户所需的各项信息，比如用户名、密码等关键信息，服务器会对这些信息进行验证和处理，以完成用户创建操作。
|
|
|
router.post("/",
|
|
|
// 第一个中间件函数，用于对创建用户时请求体中的必要参数进行验证，确保传入的参数符合业务要求，保证后续业务逻辑能正确执行。
|
|
|
// 此中间件的目的是防止因客户端传入的参数不完整或不符合要求，导致后续创建用户操作出现错误，例如数据库插入失败等情况。
|
|
|
function (req, res, next) {
|
|
|
// 检查请求体中是否包含username字段，如果不存在则返回错误响应，状态码400表示请求参数有误，同时附带提示信息"用户名不能为空"。
|
|
|
// 用户名是用于唯一标识用户的重要信息，在后续的登录、权限验证等诸多业务操作中都会用到，所以是创建用户时必须提供的关键参数。
|
|
|
if (!req.body.username) {
|
|
|
return res.sendResult(null, 400, "用户名不能为空");
|
|
|
}
|
|
|
// 检查请求体中是否包含password字段，如果不存在则返回错误响应，状态码400表示请求参数有误，同时附带提示信息"密码不能为空"。
|
|
|
// 密码用于保障用户账号的安全性，是用户登录验证身份的依据，同样是创建用户必不可少的参数。
|
|
|
if (!req.body.password) {
|
|
|
return res.sendResult(null, 400, "密码不能为空");
|
|
|
}
|
|
|
// 检查请求体中是否包含rid字段，如果不存在则将其默认设置为 -1，此处原代码有部分注释掉的返回错误逻辑，可能根据实际情况调整过，目前是默认赋值。
|
|
|
// rid字段通常代表用户的角色ID，用于确定用户在系统中所拥有的权限角色，在某些业务场景下，可能允许创建用户时暂不明确指定具体角色，所以这里默认赋值为 -1，
|
|
|
// 不过后续可能还需要根据业务规则进一步处理该默认值情况，比如提示用户及时补充角色信息或者按照默认角色赋予相应权限等操作。
|
|
|
if (!req.body.rid) {
|
|
|
req.body.rid = -1;
|
|
|
// return res.sendResult(null, 200, "角色ID不能为空");
|
|
|
}
|
|
|
// 进一步验证rid字段是否可以转换为数字类型，如果不能转换成功（即不是有效的数字），则将其默认设置为 -1，此处原代码也有部分注释掉的返回错误逻辑，目前是默认赋值处理。
|
|
|
// 一般来说，在系统设计中角色ID在数据库等存储结构里是以数字形式存在的，所以要确保传入的该参数能转换为数字类型，
|
|
|
// 若无法转换，则按照当前设定将其默认设置为 -1，但这种处理方式需根据实际业务需求判断是否合理，也可选择直接返回错误提示给客户端要求其修正参数。
|
|
|
if (isNaN(parseInt(req.body.rid))) req.body.rid = -1; // return res.sendResult(null, 200, "角色ID必须是数字");
|
|
|
// 参数验证通过后，调用next()函数将控制权传递给下一个中间件或者路由处理函数，以便继续执行后续的业务逻辑。
|
|
|
// 在Express框架的中间件机制里，next()函数起着传递请求控制权的关键作用，使得请求能按照定义的顺序依次经过各个中间件进行处理，若不调用，请求将阻塞在此中间件处。
|
|
|
next();
|
|
|
},
|
|
|
// 第二个中间件函数，用于处理创建用户的实际业务逻辑，依赖于前面验证通过的请求体参数进行相应操作。
|
|
|
// 当第一个中间件完成参数验证且验证通过后，请求会流转到此中间件，在此执行具体的创建用户操作，例如将用户信息插入到数据库中相应的用户表等存储位置。
|
|
|
function (req, res, next) {
|
|
|
// 构建一个包含创建用户所需信息的对象，从请求体中获取相应的值，如用户名（username）、密码（password）、手机号（mobile）、邮箱（email）以及角色ID（rid）等信息。
|
|
|
// 这里将从请求体中提取的各个字段整理成一个对象，方便统一传递给创建用户的服务方法，其中手机号和邮箱字段可能是可选的用户信息，根据业务规则，客户端可能可不填，但用户名和密码等关键信息已通过前面验证确保其存在。
|
|
|
params = {
|
|
|
"username": req.body.username,
|
|
|
"password": req.body.password,
|
|
|
"mobile": req.body.mobile,
|
|
|
"email": req.body.email,
|
|
|
"rid": req.body.rid
|
|
|
}
|
|
|
// 调用mgrServ用户管理服务对象的createManager方法，传入构建好的用户信息对象，用于创建新的用户。
|
|
|
// createManager方法是在ManagerService模块（从前面代码可知通过authorization模块获取）中定义的用于执行创建用户具体业务逻辑的方法，
|
|
|
// 它通常会涉及到与数据库的交互，比如构建插入语句将用户信息插入到用户表中，这是一个异步操作，所以需要通过回调函数来处理操作完成后的结果情况。
|
|
|
mgrServ.createManager(params, function (err, manager) {
|
|
|
// 如果在操作过程中出现错误（err不为null），比如数据库插入失败（可能是由于数据库连接问题、字段长度限制、唯一性约束冲突等原因），
|
|
|
// 就通过res.sendResult返回包含错误信息的响应，状态码设置为400，表示请求处理出现错误，同时将具体的错误信息（err）传递给客户端，
|
|
|
// 让客户端知晓创建用户失败的原因，以便其根据错误提示进行相应的处理，例如检查输入的参数是否符合要求、查看网络连接等情况。
|
|
|
if (err) return res.sendResult(null, 400, err);
|
|
|
// 如果创建用户操作成功，就使用res.sendResult返回包含新创建用户信息（manager）的响应，状态码为201，表示资源创建成功，
|
|
|
// 同时附带提示信息"创建成功"，告知客户端新用户已成功创建，客户端可以根据接收到的用户信息进行后续操作，比如使用新账号进行登录、查看用户详情等。
|
|
|
res.sendResult(manager, 201, "创建成功");
|
|
|
})(req, res, next);
|
|
|
}
|
|
|
);
|
|
|
|
|
|
// 定义处理修改用户信息的PUT请求的路由，路径中包含用户ID参数，格式为 "/:id"。
|
|
|
// 当客户端向服务器发送PUT请求到包含具体用户ID的路径时，服务器会依据此路由配置来处理该请求，用于更新指定用户的相关信息。
|
|
|
// 客户端需要在请求体中提供要修改的具体信息，比如手机号、邮箱等，同时通过路径中的用户ID指定要修改信息的目标用户。
|
|
|
router.put("/:id",
|
|
|
// 第一个中间件函数，用于对修改用户信息时请求中的必要参数进行验证，确保传入的用户ID参数符合业务要求，保证后续业务逻辑能正确执行。
|
|
|
// 准确获取要修改信息的目标用户是修改操作的前提，所以要先对用户ID进行严格验证，防止因参数错误导致修改了错误用户的信息或者操作失败等情况。
|
|
|
function (req, res, next) {
|
|
|
// 检查请求参数中的用户ID（req.params.id）是否存在，如果不存在则返回错误响应，状态码400表示请求参数有误，同时附带提示信息"用户ID不能为空"。
|
|
|
// 用户ID是唯一标识每个用户的关键信息，在修改用户信息的请求中，若不提供该参数，服务器无法确定要更新哪个用户的信息，所以此参数必须存在。
|
|
|
if (!req.params.id) {
|
|
|
return res.sendResult(null, 400, "用户ID不能为空");
|
|
|
}
|
|
|
// 进一步验证用户ID是否可以转换为数字类型，如果不能转换成功（即不是有效的数字），则返回错误响应，状态码同样为400，并附带提示信息"用户ID必须是数字"。
|
|
|
// 在通常的系统设计中，用户ID在数据库等存储介质里是以数字形式进行存储和标识的，所以传入的用户ID参数需要能正确转换为数字类型，
|
|
|
// 这样才能准确地与数据库中的记录进行匹配，进行后续的更新操作，若不符合要求则返回相应错误信息给客户端。
|
|
|
if (isNaN(parseInt(req.params.id))) return res.sendResult(null, 400, "用户ID必须是数字");
|
|
|
// 参数验证通过后，调用next()函数将控制权传递给下一个中间件或者路由处理函数，以便继续执行后续的业务逻辑。
|
|
|
// 通过调用next()，遵循Express中间件的执行流程，让请求能够继续流转到下一个中间件或路由处理函数中，去执行修改用户信息的具体业务逻辑。
|
|
|
next();
|
|
|
},
|
|
|
// 第二个中间件函数，用于处理修改用户信息的实际业务逻辑，依赖于前面验证通过的用户ID参数以及请求体中的其他信息进行相应操作。
|
|
|
// 在参数验证通过后，此中间件负责执行具体的修改用户信息操作，比如根据传入的用户ID找到数据库中对应的用户记录，并用请求体中提供的新信息更新相应字段。
|
|
|
function (req, res, next) {
|
|
|
// 构建一个包含要修改的用户信息的对象，包括用户ID（id）以及要更新的手机号（mobile）和邮箱（email）等信息，从请求体和请求参数中获取相应的值。
|
|
|
// 这里构建的对象明确了要更新的具体用户（通过用户ID）以及对应的要修改的信息字段，方便后续传递给更新用户信息的服务方法进行针对性的数据库更新操作，
|
|
|
// 其中用户ID已通过前面验证确保合法性，而手机号和邮箱字段则依据客户端请求体中的内容来确定是否有更新值。
|
|
|
mgrServ.updateManager(
|
|
|
{
|
|
|
"id": req.params.id,
|
|
|
"mobile": req.body.mobile,
|
|
|
"email": req.body.email
|
|
|
},
|
|
|
function (err, manager) {
|
|
|
// 这个方法执行的是异步操作，在操作过程中如果出现错误（err不为null），比如数据库更新失败（可能是由于数据库连接问题、数据约束冲突等原因），
|
|
|
// 就通过res.sendResult返回包含错误信息的响应，状态码设置为400，表示请求处理出现错误，同时将具体的错误信息（err）传递给客户端，
|
|
|
// 让客户端知晓修改用户信息失败的原因，以便其采取相应的措施，例如检查输入的更新信息是否符合要求、查看网络连接等情况。
|
|
|
if (err) return res.sendResult(null, 400, err);
|
|
|
// 如果修改用户信息操作成功，就使用res.sendResult返回包含修改后用户信息（manager）的响应，状态码为200，表示请求成功，
|
|
|
// 同时附带提示信息"更新成功"，告知客户端操作顺利完成，客户端可以根据接收到的修改后的用户信息进行相应的后续操作，比如查看更新后的用户详情等。
|
|
|
res.sendResult(manager, 200, "更新成功");
|
|
|
}
|
|
|
)(req, res, next);
|
|
|
}
|
|
|
);
|
|
|
|
|
|
// 定义处理删除用户信息的DELETE请求的路由，路径中包含用户ID参数，格式为 "/:id"。
|
|
|
// 当客户端向服务器发送DELETE请求并在路径中携带用户ID时，服务器会依据此路由配置来处理该请求，用于删除指定用户的所有相关信息。
|
|
|
// 不过在执行删除操作前，需要对用户ID进行严格验证，同时要遵循一些业务规则，比如某些特殊用户（如管理员账号）可能不允许删除。
|
|
|
router.delete("/:id",
|
|
|
// 第一个中间件函数，用于对删除用户信息时请求中的必要参数进行验证，确保传入的用户ID参数符合业务要求，保证后续业务逻辑能正确执行。
|
|
|
// 为了保证数据的安全性和业务逻辑的正确性，在执行删除操作前，必须确保传入的用户ID是合法有效的，并且要符合业务规定的删除条件。
|
|
|
function (req, res, next) {
|
|
|
// 检查请求参数中的用户ID（req.params.id）是否存在，如果不存在则返回错误响应，状态码400表示请求参数有误，同时附带提示信息"用户ID不能为空"。
|
|
|
// 用户ID是确定要删除哪个用户信息的关键标识，若请求中未提供该参数，服务器无法明确操作对象，所以必须要求其存在，否则返回错误提示让客户端补充参数后重新请求。
|
|
|
if (!req.params.id) return res.sendResult(null, 400, "用户ID不能为空");
|
|
|
// 进一步验证用户ID是否可以转换为数字类型，如果不能转换成功（即不是有效的数字），则返回错误响应，状态码同样为400，并附带提示信息"ID必须是数字"。
|
|
|
// 由于用户ID在系统存储中一般是以数字形式存在的，所以传入的参数需要能正确转换为数字，这样才能准确地找到对应的用户记录进行删除操作，若不符合要求则返回错误信息。
|
|
|
if (isNaN(parseInt(req.params.id))) return res.sendResult(null, 400, "ID必须是数字");
|
|
|
// 特别地，对于用户ID为500的情况（可能是特殊的admin账户），不允许删除，直接返回错误响应，状态码为400，并附带提示信息"不允许删除admin账户"。
|
|
|
// 在实际业务中，某些特殊的用户账号（如系统管理员账号）起着至关重要的作用，为了保障系统的正常运行和管理，通常不允许随意删除，所以在此针对这种情况进行限制，直接告知客户端不允许此操作。
|
|
|
if (req.params.id == 500) return res.sendResult(null, 400, "不允许删除admin账户");
|
|
|
// 参数验证通过后，调用next()函数将控制权传递给下一个中间件或者路由处理函数，以便继续执行后续的业务逻辑。
|
|
|
// 通过调用next()，按照Express中间件机制，让请求能够继续流转到下一个中间件去执行实际的删除用户信息的业务逻辑。
|
|
|
next();
|
|
|
},
|
|
|
// 第二个中间件函数，用于处理删除用户信息的实际业务逻辑，依赖于前面验证通过的用户ID参数进行相应操作。
|
|
|
// 在参数验证中间件通过后，此中间件负责执行具体的删除用户信息操作，比如从数据库中删除对应的用户记录以及与之相关的其他关联数据（如果有），完成删除流程并返回结果给客户端。
|
|
|
function (req, res, next) {
|
|
|
// 调用mgrServ用户管理服务对象的deleteManager方法，传入经过验证的用户ID（req.params.id），用于删除该用户的信息。
|
|
|
// deleteManager方法是在ManagerService模块中定义的用于根据传入的用户ID从数据库等数据存储中删除对应用户记录及相关关联数据（如果需要）的方法，
|
|
|
// 它会执行数据库删除操作等相关逻辑，由于涉及到与数据库的交互，这是一个异步操作，所以需要通过回调函数来处理操作完成后的结果情况，根据操作是否成功返回相应响应。
|
|
|
mgrServ.deleteManager(req.params.id, function (err) {
|
|
|
// 如果在操作过程中出现错误（err不为null），比如数据库删除失败（可能是由于数据库连接问题、外键约束等原因），
|
|
|
// 就通过res.sendResult返回包含错误信息的响应，状态码设置为400，表示请求处理出现错误，同时将具体的错误信息（err）传递给客户端，
|
|
|
// 让客户端知晓删除用户信息失败的原因，以便其根据错误提示进行相应的处理，例如检查用户ID是否正确、查看数据库相关配置等情况。
|
|
|
if (err) return res.sendResult(null, 400, err);
|
|
|
// 如果删除用户信息操作成功，就使用res.sendResult返回一个空数据的响应（因为用户信息已被删除），状态码为200，表示请求成功，
|
|
|
// 同时附带提示信息"删除成功"，告知客户端操作顺利完成，客户端可以根据此响应知晓对应的用户信息已成功从服务器端删除。
|
|
|
return res.sendResult(null, 200, "删除成功");
|
|
|
})(req, res, next);
|
|
|
}
|
|
|
);
|
|
|
|
|
|
// 定义处理分配用户角色的PUT请求的路由，路径中包含用户ID和角色相关的路径参数，格式为 "/:id/role"。
|
|
|
// 当客户端向服务器发送PUT请求到包含用户ID和角色相关路径参数的这个路径时，服务器会依据此路由配置来处理该请求，用于为指定用户分配相应的角色。
|
|
|
// 客户端需要在请求体中提供角色ID（rid），并通过路径中的用户ID指定要分配角色的目标用户，同时要遵循一定的业务规则，比如某些特殊用户角色可能不允许修改。
|
|
|
router.put("/:id/role",
|
|
|
// 第一个中间件函数，用于对分配用户角色时请求中的必要参数进行验证，确保传入的参数符合业务要求，保证后续业务逻辑能正确执行。
|
|
|
// 在进行角色分配操作前，需要确保传入的用户ID和角色ID等关键参数是合法有效的，并且符合业务规则，以防止错误的角色分配情况发生。
|
|
|
function (req, res, next) {
|
|
|
// 检查请求参数中的用户ID（req.params.id）是否存在，如果不存在则返回错误响应，状态码400表示请求参数有误，同时附带提示信息"用户ID不能为空"。
|
|
|
// 用户ID是确定要为哪个用户分配角色的关键标识，若请求中未提供该参数，服务器无法明确操作对象，所以此参数必须存在，否则返回错误提示让客户端补充参数后重新请求。
|
|
|
if (!req.params.id) {
|
|
|
return res.sendResult(null, 400, "用户ID不能为空");
|
|
|
}
|
|
|
// 进一步验证用户ID是否可以转换为数字类型，如果不能转换成功（即不是有效的数字），则返回
|
|
|
if (isNaN(parseInt(req.params.id))) return res.sendResult(null, 400, "用户ID必须是数字");
|
|
|
// 对于用户ID为500的情况（可能是特殊的admin账户），不允许修改角色，直接返回错误响应，状态码为400，并附带提示信息"不允许修改admin账户"
|
|
|
if (req.params.id == 500) return res.sendResult(null, 400, "不允许修改admin账户");
|
|
|
// 检查请求体中是否包含rid字段，如果不存在则返回错误响应，状态码400，表示请求参数有误，同时附带提示信息"权限ID不能为空"
|
|
|
if (!req.body.rid) res.sendResult(null, 400, "权限ID不能为空");
|
|
|
// 参数验证通过后，调用next()函数将控制权传递给下一个中间件或者路由处理函数，以便继续执行后续的业务逻辑
|
|
|
next();
|
|
|
},
|
|
|
// 第二个中间件函数，用于处理分配用户角色的实际业务逻辑，依赖于前面验证通过的用户ID和请求体中的角色ID参数进行相应操作
|
|
|
function (req, res, next) {
|
|
|
// 调用mgrServ用户管理服务对象的setRole方法，传入经过验证的用户ID（req.params.id）和角色ID（req.body.rid），用于为用户设置相应的角色。
|
|
|
// 这个方法执行的是异步操作，在操作过程中如果出现错误（err不为null），就通过res.sendResult返回包含错误信息的响应，状态码设置为400，表示请求处理出现错误。
|
|
|
// 如果分配用户角色操作成功，就使用res.sendResult返回包含更新后用户信息（manager）的响应，状态码为200，表示请求成功，同时附带提示信息"设置角色成功"，告知客户端操作顺利完成
|
|
|
mgrServ.setRole(req.params.id, req.body.rid, function (err, manager) {
|
|
|
if (err) return res.sendResult(null, 400, err);
|
|
|
res.sendResult(manager, 200, "设置角色成功");
|
|
|
})(req, res, next);
|
|
|
}
|
|
|
);
|
|
|
|
|
|
// 定义处理更新用户状态的PUT请求的路由，路径中包含用户ID和状态相关的路径参数，格式为 "/:id/state/:state"
|
|
|
router.put("/:id/state/:state",
|
|
|
// 第一个中间件函数，用于对更新用户状态时请求中的必要参数进行验证，确保传入的参数符合业务要求，保证后续业务逻辑能正确
|
|
|
// 参数验证
|
|
|
function(req,res,next) {
|
|
|
if(!req.params.id) {
|
|
|
return res.sendResult(null,400,"用户ID不能为空");
|
|
|
}
|
|
|
if(isNaN(parseInt(req.params.id))) return res.sendResult(null,400,"用户ID必须是数字");
|
|
|
|
|
|
// // // if(!req.params.state) {
|
|
|
// // // return res.sendResult(null,400,"状态不能为空");
|
|
|
// // // }
|
|
|
// // if(isNaN(parseInt(req.params.state))) return res.sendResult(null,400,"状态必须是数字");
|
|
|
// if(parseInt(req.params.state) != 0 && parseInt(req.params.state) != 1) return res.sendResult(null,400,"管理状态只能为0或1");
|
|
|
|
|
|
next();
|
|
|
},
|
|
|
// 处理业务逻辑
|
|
|
function(req,res,next) {
|
|
|
state = 0
|
|
|
if(req.params.state && req.params.state == "true") state = 1
|
|
|
mgrServ.updateMgrState(req.params.id,state,function(err,manager){
|
|
|
if(err) return res.sendResult(null,400,err);
|
|
|
res.sendResult(manager,200,"设置状态成功");
|
|
|
})(req,res,next);
|
|
|
}
|
|
|
)
|
|
|
|
|
|
module.exports = router;
|
|
|
//这段代码整体围绕用户管理中的角色分配和用户状态更新这两个功能模块，通过定义路由、进行参数验证
|
|
|
//以及执行具体的业务逻辑操作，实现了对用户相关信息的有效管理和更新，同时保障了操作的合法性和数
|
|
|
//据的准确性，遵循了良好的后端服务开发的流程和规范，在构建 Web 应用的用户管理系统等场景中具有
|
|
|
//重要作用。
|
