From bbfa7d5b2f8be307f66b249ddcf9c9e044efcecc Mon Sep 17 00:00:00 2001 From: gj <1049091121@qq.com> Date: Thu, 19 Dec 2024 16:26:59 +0800 Subject: [PATCH] =?UTF-8?q?=E8=B0=B7=E5=81=A5git=E6=B5=8B=E8=AF=95?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../bus/controller/GoodsController.java | 133 ++++++++++++++++++ .../bus/controller/InportController.java | 126 +++++++++++++++++ .../bus/controller/OutportController.java | 98 +++++++++++++ .../bus/controller/ProviderController.java | 87 ++++++++++++ .../bus/controller/SalesController.java | 2 +- .../bus/controller/SalesbackController.java | 100 +++++++++++++ 6 files changed, 545 insertions(+), 1 deletion(-) diff --git a/src/main/java/com/yeqifu/bus/controller/GoodsController.java b/src/main/java/com/yeqifu/bus/controller/GoodsController.java index 7ecb48c..cb49def 100644 --- a/src/main/java/com/yeqifu/bus/controller/GoodsController.java +++ b/src/main/java/com/yeqifu/bus/controller/GoodsController.java @@ -182,3 +182,136 @@ public class GoodsController { } +// GoodsController类，使用了@RestController注解，表明它是Spring框架下用于构建RESTful API的控制器类，主要负责处理与商品（Goods）相关的各种HTTP请求， +// 并将处理结果以合适的格式（如JSON）返回给客户端（通常是前端应用），在前后端交互中起着关键的桥梁作用，方便前端对商品信息进行查询、添加、修改、删除等操作。 +// 通过@RequestMapping("/goods")注解，为该控制器下所有的请求映射路径设置了公共前缀"/goods"，便于对商品相关的接口进行统一管理和分类，便于代码维护以及前端接口调用。 + + + // 使用@Autowired注解自动注入IGoodsService接口的实现类对象，通过这个服务对象，可以调用与商品相关的核心业务逻辑方法， + // 例如分页查询商品信息、添加商品、更新商品信息、删除商品以及获取库存预警商品等操作，具体的业务实现细节则在IGoodsService接口对应的实现类中完成，这里只是进行调用触发相应的业务逻辑流程。 + + + // 通过@Autowired注解注入IProviderService接口的实现类对象，用于获取供应商相关的业务服务。在查询商品信息、加载可用商品等操作时，借助该服务根据供应商ID查询供应商的详细信息， + // 以便将供应商名称等相关信息补充到商品记录中，使返回给前端的数据更加完整，方便前端展示和业务操作时能呈现更全面的供应商相关情况，让用户清楚知道商品对应的供应商是谁。 + + + /** + * 查询商品 + * @param goodsVo 这是一个封装了查询条件的对象，通常包含分页相关信息（如页码、每页显示数量）以及其他筛选条件（如供应商ID、商品名称、产品编码、助记码、描述、规格等），由前端传入， + * 方便后端统一处理各种不同的查询需求，根据这些条件从数据库中准确获取符合要求的商品记录。 + * @return 返回一个DataGridView对象，该对象一般是项目中自定义用于封装数据展示相关信息的，其中包含了查询到的商品记录的总数量以及具体的商品记录列表， + * 方便前端进行分页展示以及对数据进行进一步的处理和分析等操作，例如前端可以根据这些数据展示商品列表、进行数据统计等。 + */ + + // 创建一个IPage对象，用于实现分页功能，通过传入从goodsVo对象中获取的当前页码（goodsVo.getPage()）和每页显示记录数量（goodsVo.getLimit()）来确定分页范围， + // 例如，当页码为2且每页显示数量为10时，表示要获取第2页，每页显示10条商品记录的那部分数据，这样可以对大量的商品记录进行分页管理，提升前端展示效果以及用户查看数据的体验。 + + + // 创建一个QueryWrapper对象，用于构建查询条件，它类似于构建SQL语句中的WHERE子句部分，能够灵活地添加各种筛选条件，从而精确地查询出符合特定要求的商品记录。 + + + // 对供应商进行查询，如果从goodsVo对象中获取的供应商ID（goodsVo.getProviderid()）不为空且不等于0，说明前端传入了供应商筛选条件， + // 则添加一个相等性查询条件，在数据库表中对应"providerid"字段，查找与传入的供应商ID相等的商品记录，以此实现按供应商来筛选商品信息的功能，方便查看特定供应商提供的商品情况。 + + // 对商品名称进行模糊查询，如果从goodsVo对象中获取的商品名称（goodsVo.getGoodsname()）不为空字符串（通过StringUtils.isNotBlank方法判断）， + // 则添加一个模糊查询条件，在数据库表中对应"goodsname"字段，查找包含传入商品名称的商品记录，便于根据部分商品名称来查找相关商品，满足更灵活的查询需求。 + + // 对产品编码进行模糊查询，同理，当goodsVo对象中获取的产品编码（goodsVo.getProductcode()）不为空字符串时，添加一个模糊查询条件， + // 在数据库表的"productcode"字段上进行模糊匹配，查找包含传入产品编码的商品记录，方便根据产品编码来定位商品。 + + // 对助记码进行模糊查询，若goodsVo对象中获取的助记码（goodsVo.getPromitcode()）不为空字符串，就在"promitcode"字段添加模糊查询条件， + // 查找包含传入助记码的商品记录，有助于通过助记码快速查找特定商品，提高查询的便捷性。 + + // 对商品描述进行模糊查询，当goodsVo对象中获取的描述信息（goodsVo.getDescription()）不为空字符串时，添加一个模糊查询条件， + // 在数据库表的"description"字段进行模糊匹配，查找包含传入描述内容的商品记录，方便根据商品的相关描述来查找商品。 + + // 对商品规格进行模糊查询，类似地，若goodsVo对象中获取的规格信息（goodsVo.getSize()）不为空字符串，就在"size"字段添加模糊查询条件， + // 查找包含传入规格的商品记录，便于根据商品规格来筛选商品，满足不同业务场景下对商品数据的查询需求。 + + // 通过商品的ID对查询结果进行降序排序，添加一个按照"id"字段（推测是商品的唯一标识符字段）进行降序排序的条件，使得查询返回的商品记录按照ID从大到小的顺序排列， + // 这样在前端展示时，用户能先看到较新添加或更新的商品记录，更符合一般的数据查看习惯，方便查看和分析近期的商品情况。 + // 调用goodsService的page方法，传入构建好的分页对象page和查询条件包装器queryWrapper，服务层会根据这些条件执行数据库查询操作， + // 获取符合条件的商品数据，并将数据填充到page对象中，例如设置page对象中的总记录数、当前页的记录列表等属性，以便后续返回完整的分页数据信息。 + + // 获取查询结果中当前页的商品记录列表，方便后续对每条记录进行补充相关信息的操作，比如添加供应商名称等，使返回给前端的数据更加丰富详细，更具业务价值。 + + // 遍历当前页查询到的每条商品记录，为每条记录补充供应商名称信息，使其展示的数据更加完整全面，方便前端展示以及业务查看和操作使用。 + // 通过providerService的getById方法，根据当前商品记录中的供应商ID（goods.getProviderid()）从数据库中查询对应的供应商详细信息，获取到一个Provider对象（如果存在的话）。 + // 如果查询到了对应的供应商信息，将供应商的名称设置到当前商品记录（goods）中，以便前端展示商品记录时能同时显示供应商名称，让数据更直观、完整，便于业务人员查看商品对应的供应商情况。 + + + // 创建一个DataGridView对象，将查询得到的商品记录的总数量（通过page.getTotal()获取）以及当前页补充完整信息后的商品记录列表（page.getRecords()）进行封装， + // 最终返回给前端，使得前端能够按照分页逻辑展示商品信息，并且展示的数据包含了丰富的关联信息（供应商名称等），满足业务查看和操作的实际需求。 + + /** + * 添加商品 + * @param goodsVo 这是一个包含了要添加的商品相关信息的对象，通常由前端传入，里面封装了如商品名称、供应商ID、产品编码、助记码、描述、规格、商品图片等诸多与商品业务相关的属性信息， + * 这些信息将被保存到数据库中，形成一条新的商品记录。 + * @return 返回一个ResultObj类型的结果对象，ResultObj中定义了诸如ADD_SUCCESS、ADD_ERROR等枚举值，用于明确表示添加商品操作的成功或失败状态， + * 方便前端根据接收到的返回结果进行相应的提示操作或者后续处理，比如提示用户添加成功或者告知添加失败的原因等。 + */ + + // 打印商品图片相关信息（可能用于调试查看图片相关情况，比如确认前端传入的图片路径等是否正确），此处输出只是辅助开发阶段查看相关数据情况，在正式环境可根据需求决定是否保留。 + + + // 判断商品图片路径是否不为空且以"_temp"结尾，如果满足该条件，说明可能是临时的图片文件名，需要进行重命名处理。 + + // 调用AppFileUtils的renameFile方法对临时的商品图片文件名进行重命名操作，得到新的文件名，并将新文件名设置回goodsVo对象的"goodsimg"属性中， + // 以便后续保存商品信息时使用正确的图片文件名，保证图片存储和关联的正确性。 + + + // 调用goodsService的save方法，将包含完整商品信息（已处理好图片文件名等情况）的goodsVo对象传递过去，触发服务层中处理添加商品的业务逻辑， + // 该逻辑可能涉及到向数据库的商品表中插入一条新记录、将商品图片存储到指定的文件存储位置（如果有图片存储相关逻辑）以及其他关联业务模块的数据交互等一系列复杂操作， + // 如果整个操作过程顺利完成，不会抛出异常；若在执行过程中出现问题（比如数据库插入失败、文件存储失败、业务规则校验不通过等情况），则会抛出异常。 + + // 如果在添加商品的过程中出现异常，通过打印异常堆栈信息（这有助于开发人员在排查问题时了解详细的异常发生位置和原因）， + // 然后返回表示添加商品失败的ResultObj.ADD_ERROR结果对象给前端，使得前端能够知晓操作未成功，进而采取相应的提示告知用户或者其他补救措施等。 + + + /** + * 修改商品 + * @param goodsVo 这是一个包含了要修改的商品新信息的对象，通常由前端传入，里面的属性值是修改后的值，通过与数据库中已存在的商品记录的主键等信息进行匹配来确定要更新的具体记录， + // 例如修改商品名称、规格、图片等信息后，将新的值封装在这个对象中传递过来进行更新操作。 + * @return 返回一个ResultObj类型的结果对象，ResultObj中定义了如UPDATE_SUCCESS、UPDATE_ERROR等枚举值，用于表示修改商品操作的成功或失败状态， + * 方便前端根据返回结果进行相应的处理或提示用户，比如提示用户更新成功或者告知更新失败的原因等。 + */ + + // 判断商品图片是否不是默认图片，这里通过判断图片路径不为空且不等于默认图片路径（Constast.DEFAULT_IMG_GOODS，应该是项目中定义的表示默认商品图片的常量）来确定， + // 如果不是默认图片，说明可能需要进行图片相关的更新处理操作，比如更换了商品图片等情况。 + + + // 进一步判断商品图片路径是否以"_temp"结尾，如果是，说明可能是新上传的临时图片文件名，需要进行重命名处理，以符合实际存储和使用的规范。 + + // 调用AppFileUtils的renameFile方法对临时的商品图片文件名进行重命名操作，得到新的文件名，并将新文件名设置回goodsVo对象的"goodsimg"属性中， + // 确保后续更新商品信息时使用正确的图片文件名进行关联。 + + + // 获取原先商品记录中的图片路径，通过调用goodsService的getById方法根据商品ID（goodsVo.getId()）获取对应的商品记录，再获取其图片路径（getGoodsimg方法）， + // 以便后续删除原来的旧图片，避免图片文件冗余，保持文件存储与商品信息的一致性。 + + // 调用AppFileUtils的removeFileByPath方法，根据获取到的旧图片路径删除原先的商品图片文件，实现图片文件的更新替换操作。 + + + // 调用goodsService的updateById方法，将包含更新后商品信息的goodsVo对象传递过去，服务层会根据对象中的主键信息（通常是商品记录的ID）， + // 在数据库中找到对应的商品记录，并将其他属性值更新为goodsVo对象中传入的新值，实现更新商品信息的功能，例如修改商品记录中的名称、规格等字段的值， + // 如果更新操作顺利完成则无异常抛出，若出现问题（比如找不到对应记录、更新数据违反约束等情况）则会抛出异常。 + + // 如果在更新商品信息的过程中出现异常，打印异常堆栈信息（便于开发人员排查问题根源），然后返回表示更新操作失败的ResultObj.UPDATE_ERROR结果对象给前端， + // 让前端知晓更新操作未成功，以便采取相应的提示或者其他处理措施，比如告知用户更新失败，可尝试再次操作等。 + + + /** + * 删除商品 + * @param id 要删除的商品记录的唯一标识符（通常是主键ID），由前端传入，通过这个ID来确定要从数据库中删除的具体商品记录。 + * @param goodsimg 商品图片的路径，用于定位要删除的商品图片文件，确保在删除商品记录的同时，将对应的商品图片文件也从存储中删除，保持数据的一致性。 + * @return 返回一个ResultObj类型的结果对象，ResultObj中定义了如DELETE_SUCCESS、DELETE_ERROR等枚举值，用于表示删除商品操作的成功或失败状态， + * 方便前端根据返回结果进行相应的处理或提示用户，比如提示用户删除成功或者告知删除失败的原因等。 + */ + + // 调用AppFileUtils的removeFileByPath方法，根据传入的商品图片路径（goodsimg）删除对应的商品图片文件，实现删除商品图片的操作， + // 避免商品记录删除后图片文件仍残留，浪费存储空间且可能导致数据不一致的问题。 + + // 调用goodsService的deleteGoodsById方法（假设该方法用于根据商品ID删除商品记录，具体实现逻辑在IGoodsService接口对应的实现类中），传入要删除的商品ID， + // 服务层会根据这个ID在数据库中找到对应的商品记录并执行删除操作，实现删除商品记录的功能， + // 如果删除操作顺利完成则无异常抛出，若出现问题（比如存在关联数据、违反数据库约束等情况）则会抛出异常。 + diff --git a/src/main/java/com/yeqifu/bus/controller/InportController.java b/src/main/java/com/yeqifu/bus/controller/InportController.java index 2c17889..d8cf844 100644 --- a/src/main/java/com/yeqifu/bus/controller/InportController.java +++ b/src/main/java/com/yeqifu/bus/controller/InportController.java @@ -139,3 +139,129 @@ public class InportController { } + +// InportController类，使用了@RestController注解，表明它是Spring框架下用于构建RESTful API的控制器类，主要负责处理与商品进货（Inport）相关的HTTP请求， +// 并将处理结果以合适的格式（如JSON）返回给客户端（通常是前端应用），起到了在前后端之间传递和处理商品进货业务数据的桥梁作用。同时，通过@RequestMapping("inport")注解， +// 为该控制器下所有的请求映射路径设置了公共前缀"inport"，便于对商品进货相关的接口进行统一管理和分类，方便前端进行接口调用以及后端进行代码维护。 + + + // 使用@Autowired注解自动注入IInportService接口的实现类对象，通过这个服务对象，可以调用与商品进货相关的核心业务逻辑方法， + // 比如分页查询进货记录、添加进货商品、更新进货商品信息以及删除进货商品等操作，具体的业务实现细节则在IInportService接口对应的实现类中完成，这里只是进行调用触发相应的业务逻辑流程。 + + + // 通过@Autowired注解注入IProviderService接口的实现类对象，用于获取供应商相关的业务服务。在查询商品进货信息时，借助该服务根据供应商ID查询供应商的详细信息， + // 以便将供应商姓名等相关信息补充到进货记录中，使返回给前端的数据更加完整，方便前端展示和业务操作时能呈现更全面的供应商相关情况，例如让用户清楚知道每笔进货对应的供应商是谁。 + + // 同样使用@Autowired注解注入IGoodsService接口的实现类对象，用于获取商品相关的业务服务。在处理进货记录查询结果或者添加、更新进货商品信息时，通过该服务依据商品ID查询商品详情（如商品名称、规格等）， + // 然后将这些商品相关信息设置到进货记录中，进一步丰富返回给前端的数据内容，让前端能够展示更详细的商品相关信息，便于业务查看和分析商品进货情况，比如了解进货的具体商品是什么以及其规格特点等。 + + + /** + * 查询商品进货 + * @param inportVo 这是一个封装了查询条件的对象，通常包含分页相关信息（如页码、每页显示数量）以及其他筛选条件（如供应商ID、商品ID、时间范围等），由前端传入， + * 方便后端统一处理各种不同的查询需求，根据这些条件从数据库中准确获取符合要求的商品进货记录。 + * @return 返回一个DataGridView对象，该对象一般是项目中自定义用于封装数据展示相关信息的，其中包含了查询到的商品进货记录的总数量以及具体的进货记录列表， + * 方便前端进行分页展示以及对数据进行进一步的处理和分析等操作，例如前端可以根据这些数据展示进货记录列表、进行数据统计等。 + */ + + // 创建一个IPage对象，用于实现分页功能，通过传入从inportVo对象中获取的当前页码（inportVo.getPage()）和每页显示记录数量（inportVo.getLimit()）来确定分页范围， + // 例如，当页码为2且每页显示数量为10时，表示要获取第2页，每页显示10条商品进货记录的那部分数据，这样可以对大量的进货记录进行分页管理，提升前端展示效果以及用户查看数据的体验。 + + // 创建一个QueryWrapper对象，用于构建查询条件，它类似于构建SQL语句中的WHERE子句部分，能够灵活地添加各种筛选条件，从而精确地查询出符合特定要求的商品进货记录。 + + // 对供应商进行查询，如果从inportVo对象中获取的供应商ID（inportVo.getProviderid()）不为空且不等于0，说明前端传入了供应商筛选条件， + // 则添加一个相等性查询条件，在数据库表中对应"providerid"字段，查找与传入的供应商ID相等的进货记录，以此实现按供应商来筛选进货信息的功能，方便查看特定供应商的进货情况，例如查看某个供应商的历史进货记录。 + + // 对商品进行查询，同理，当inportVo对象中获取的商品ID（inportVo.getGoodsid()）不为空且不等于0时，表明前端传入了商品筛选条件， + // 就在数据库表的"goodsid"字段添加相等性查询条件，查找与传入商品ID匹配的进货记录，便于根据具体商品来查询其进货情况，满足不同业务场景下对商品进货数据的查询需求，比如查看某类商品的进货频次、数量等情况。 + + + // 对时间进行查询要求大于开始时间小于结束时间，当inportVo对象中的开始时间（inportVo.getStartTime()）不为空时，添加一个大于等于（ge）的查询条件， + // 在数据库表的"inporttime"字段（推测是商品进货时间字段）上，筛选出进货时间大于等于传入的开始时间的进货记录；同样，当结束时间（inportVo.getEndTime()）不为空时， + // 添加一个小于等于（le）的查询条件，筛选出进货时间小于等于传入的结束时间的进货记录，这样就能获取到处于指定时间范围内的商品进货信息，方便按时间区间进行数据查询、统计分析等操作， + // 例如查看某个时间段内的进货总量、不同供应商在该时间段的进货情况等。 + + + // 通过进货时间对商品进行排序，添加一个按照"inporttime"字段（商品进货时间）进行降序排序的条件，使得查询返回的进货记录按照进货时间从近到远的顺序排列， + // 这样在前端展示时，用户能先看到较新的进货记录，更符合一般的数据查看习惯，方便查看和分析近期的进货情况，有助于及时掌握最新的进货动态、发现潜在问题等。 + + // 调用inportService的page方法，传入构建好的分页对象page和查询条件包装器queryWrapper，服务层会根据这些条件执行数据库查询操作， + // 获取符合条件的商品进货数据，并将数据填充到page对象中，例如设置page对象中的总记录数、当前页的记录列表等属性，以便后续返回完整的分页数据信息。 + + // 获取查询结果中当前页的进货记录列表，方便后续对每条记录进行补充相关信息的操作，比如添加供应商姓名、商品名称和规格等，使返回给前端的数据更加丰富详细，更具业务价值。 + + // 遍历当前页查询到的每条商品进货记录，为每条记录补充供应商姓名、商品名称和规格等信息，使其展示的数据更加完整全面，方便前端展示以及业务查看和操作使用。 + + // 通过providerService的getById方法，根据当前进货记录中的供应商ID（inport.getProviderid()）从数据库中查询对应的供应商详细信息，获取到一个Provider对象（如果存在的话）。 + + + // 如果查询到了对应的供应商信息，将供应商的姓名设置到当前进货记录（inport）中，以便前端展示进货记录时能同时显示供应商姓名，让数据更直观、完整，便于业务人员查看相关供应商的进货情况。 + + // 通过goodsService的getById方法，依据当前进货记录中的商品ID（inport.getGoodsid()）从数据库中查询对应的商品详细信息，获取到一个Goods对象（若存在的话）。 + + + // 如果查询到了商品信息，将商品的名称设置到当前进货记录（inport）中，方便前端展示进货记录时能呈现商品名称，使数据更具可读性，便于了解进货商品的具体情况。 + + // 同时将商品的规格信息也设置到当前进货记录（inport）中，进一步丰富进货记录展示的数据内容，方便业务人员更详细地掌握进货商品的规格特点等信息。 + + + + // 创建一个DataGridView对象，将查询得到的商品进货记录的总数量（通过page1.getTotal()获取）以及当前页补充完整信息后的进货记录列表（page1.getRecords()）进行封装， + // 最终返回给前端，使得前端能够按照分页逻辑展示商品进货信息，并且展示的数据包含了丰富的关联信息（供应商姓名、商品名称和规格等），满足业务查看和操作的实际需求。 + + + /** + * 添加进货商品 + * @param inportVo 这是一个包含了要添加的进货商品相关信息的对象，通常由前端传入，里面封装了如商品ID、供应商ID、进货数量、进货价格等诸多与进货业务相关的属性信息， + * 这些信息将被保存到数据库中，形成一条新的进货记录。 + * @return 返回一个ResultObj类型的结果对象，ResultObj中定义了诸如ADD_SUCCESS、ADD_ERROR等枚举值，用于明确表示添加进货商品操作的成功或失败状态， + * 方便前端根据接收到的返回结果进行相应的提示操作或者后续处理，比如提示用户添加成功或者告知添加失败的原因等。 + */ + + // 获得当前系统用户，通过从WebUtils获取当前会话（HttpSession），并从中获取名为"user"的属性（推测是在用户登录成功后将用户信息存储在了会话中）， + // 然后将其强制转换为User类型，这样就能获取到当前操作的用户对象，后续可以利用该用户信息记录是谁进行了此次进货操作等相关业务逻辑。 + + // 设置操作人，将获取到的当前用户的姓名（通过user.getName()获取）设置到inportVo对象中，用于记录此次进货操作是由哪个用户执行的， + // 这样在数据库的进货记录中就能明确体现操作人信息，方便后续进行操作记录查询、责任追溯等业务需求。 + + + // 设置进货时间，创建一个新的Date对象（代表当前时间），并将其设置到inportVo对象的"inporttime"属性中，以此记录此次进货业务发生的具体时间， + // 确保进货记录中的时间信息准确无误，便于后续按照时间进行数据查询、统计分析等操作。 + + // 调用inportService的save方法，将包含完整进货信息（已设置好操作人、进货时间等）的inportVo对象传递过去，触发服务层中处理添加进货商品的业务逻辑， + // 该逻辑可能涉及到向数据库的进货表中插入一条新记录、更新库存数量（增加对应商品的库存）以及其他关联业务模块的数据交互等一系列复杂操作， + // 如果整个操作过程顺利完成，不会抛出异常；若在执行过程中出现问题（比如数据库插入失败、业务规则校验不通过等情况），则会抛出异常。 + + // 如果在添加进货商品的过程中出现异常，通过打印异常堆栈信息（这有助于开发人员在排查问题时了解详细的异常发生位置和原因）， + // 然后返回表示添加进货商品失败的ResultObj.ADD_ERROR结果对象给前端，使得前端能够知晓操作未成功，进而采取相应的提示告知用户或者其他补救措施等。 + + + /** + * 更新进货商品 + * @param inportVo 这是一个包含了要更新的进货商品新信息的对象，通常由前端传入，里面的属性值是修改后的值，通过与数据库中已存在的进货记录的主键等信息进行匹配来确定要更新的具体记录， + * 例如修改进货数量、进货价格等信息后，将新的值封装在这个对象中传递过来进行更新操作。 + * @return 返回一个ResultObj类型的结果对象，ResultObj中定义了如UPDATE_SUCCESS、UPDATE_ERROR等枚举值，用于表示更新进货商品操作的成功或失败状态， + // 方便前端根据返回结果进行相应的处理或提示用户，比如提示用户更新成功或者告知更新失败的原因等。 + */ + + + // 调用inportService的updateById方法，将包含更新后进货商品信息的inportVo对象传递过去，服务层会根据对象中的主键信息（通常是进货记录的ID）， + // 在数据库中找到对应的进货记录，并将其他属性值更新为inportVo对象中传入的新值，实现更新进货商品信息的功能，例如修改进货记录中的数量、价格等字段的值， + // 如果更新操作顺利完成则无异常抛出，若出现问题（比如找不到对应记录、更新数据违反约束等情况）则会抛出异常。 + + // 如果在更新进货商品信息的过程中出现异常，打印异常堆栈信息（便于开发人员排查问题根源），然后返回表示更新操作失败的ResultObj.UPDATE_ERROR结果对象给前端， + // 让前端知晓更新操作未成功，以便采取相应的提示或者其他处理措施，比如告知用户更新失败，可尝试再次操作等。 + + + /** + * 删除进货商品 + * @param id 要删除的进货商品记录的唯一标识符（通常是主键ID），由前端传入，通过这个ID来确定要从数据库中删除的具体进货记录。 + * @return 返回一个ResultObj类型的结果对象，ResultObj中定义了如DELETE_SUCCESS、DELETE_ERROR等枚举值，用于表示删除进货商品操作的成功或失败状态， + * 方便前端根据返回结果进行相应的处理或提示用户，比如提示用户删除成功或者告知删除失败的原因等。 + */ + + // 调用inportService的removeById方法，传入要删除的进货记录的ID，服务层会根据这个ID在数据库中找到对应的进货记录并执行删除操作， + // 如果删除操作顺利完成则无异常抛出，若出现问题（比如存在关联数据、违反数据库约束等情况）则会抛出异常。 + + // 如果在删除进货商品的过程中出现异常，打印异常堆栈信息（便于开发人员排查问题根源），然后返回表示删除操作失败的ResultObj.DELETE_ERROR结果对象给前端， + // 让前端知晓删除操作未成功，以便采取相应的提示或者其他处理措施，比如告知用户删除失败，可尝试再次操作等。 diff --git a/src/main/java/com/yeqifu/bus/controller/OutportController.java b/src/main/java/com/yeqifu/bus/controller/OutportController.java index fb557a4..49f77cf 100644 --- a/src/main/java/com/yeqifu/bus/controller/OutportController.java +++ b/src/main/java/com/yeqifu/bus/controller/OutportController.java @@ -114,3 +114,101 @@ public class OutportController { } + +// OutportController类，使用了@RestController注解，表明这是一个Spring框架中的RESTful风格的控制器类， +// 用于处理与商品退货（Outport）相关的HTTP请求，并将处理结果以JSON等格式返回给客户端（通常是前端页面），是连接前端与后端业务逻辑的重要环节。 +// 同时通过@RequestMapping("/outport")注解，为该控制器下的所有请求映射路径设置了一个公共的前缀"/outport"，方便对相关的API进行统一管理和区分。 + + + // 使用@Autowired注解自动注入IOutportService接口的实现类对象，用于调用与商品退货相关的业务逻辑方法， + // 例如添加退货信息、分页查询退货记录、删除退货信息等操作，具体的业务实现是在对应的服务层接口实现类中完成的，这里只是进行调用触发相应逻辑。 + + + // 同样通过@Autowired注解注入IProviderService接口的实现类对象，用于获取供应商相关的业务服务， + // 在查询商品退货信息时，会借助该服务根据供应商ID查询供应商详细信息，以便补充到退货记录中展示更完整的数据。 + + // 注入IGoodsService接口的实现类对象，用于获取商品相关的业务服务，在查询商品退货信息时，通过该服务依据商品ID查询商品详情（如名称、规格等）， + // 然后将这些商品相关信息设置到退货记录中，使返回给前端的数据更加丰富全面，方便前端展示和业务操作。 + + /** + * 添加退货信息 + * @param id 进货单ID，用于明确此次退货操作是针对哪一笔进货业务进行的，是关联到具体进货记录的关键标识，由前端传入。 + * @param number 退货数量，指定了要退回商品的具体数量，这个数量信息对于后续更新库存、统计退货数据等业务操作至关重要，同样由前端传入。 + * @param remark 备注，用于记录一些额外的关于此次退货的相关情况说明，比如退货原因（是商品质量问题、数量不符还是其他原因等）、特殊的退货协商结果等内容，也是由前端传入。 + * @return 返回一个ResultObj类型的结果对象，ResultObj中定义了诸如BACKINPORT_SUCCESS、BACKINPORT_ERROR等枚举值，用于明确表示添加退货信息操作的成功或失败状态，以便前端根据返回结果进行相应提示或处理。 + */ + + // 调用outportService的addOutport方法，将前端传入的进货单ID、退货数量和备注信息传递过去，触发服务层的添加退货信息业务逻辑， + // 该逻辑可能涉及到更新库存、在数据库中插入退货记录、处理与财务等相关模块的数据交互等一系列复杂操作，如果操作顺利完成则无异常抛出，若过程中出现问题（比如数据库操作失败、业务规则校验不通过等）则会抛出异常。 + + // 如果在添加退货信息过程中出现异常，打印异常堆栈信息（方便开发人员排查问题根源），然后返回表示添加退货信息失败的ResultObj.BACKINPORT_ERROR结果对象给前端， + // 使得前端能够知晓操作未成功，进而进行相应的提示告知用户或者采取其他补救措施等。 + + + /** + * 查询商品退货 + * @param outportVo 这是一个封装了查询条件的对象，通常包含分页相关信息（如页码、每页显示数量）以及其他筛选条件（如供应商ID、商品ID、时间范围等），由前端传入，方便在后端统一处理各种查询需求。 + * @return 返回一个DataGridView对象，该对象一般是项目中自定义用于封装数据展示相关信息的，这里面包含了查询到的商品退货记录的总数量以及具体的退货记录列表，方便前端进行分页展示和数据处理等操作。 + */ + + + // 创建一个IPage对象，用于实现分页功能，通过传入从outportVo对象中获取的当前页码（outportVo.getPage()）和每页显示记录数量（outportVo.getLimit()）来确定分页范围， + // 例如，当页码为2且每页显示数量为10时，表示要获取第2页，每页显示10条商品退货记录的那部分数据，方便对大量退货记录进行分页展示，提升前端展示和用户查看数据的体验。 + + + // 创建一个QueryWrapper对象，用于构建查询条件，类似于构建SQL语句中的WHERE子句部分，方便灵活地添加各种筛选条件来精确查询符合要求的商品退货记录。 + + + // 对供应商进行查询，如果outportVo对象中获取的供应商ID（outportVo.getProviderid()）不为空且不等于0，说明前端传入了供应商筛选条件， + // 则添加一个相等性查询条件，在数据库表中对应"providerid"字段，查找与传入的供应商ID相等的退货记录，以此实现按供应商筛选退货信息的功能。 + + + // 对商品进行查询，同理，当outportVo对象中获取的商品ID（outportVo.getGoodsid()）不为空且不等于0时，表明前端传入了商品筛选条件， + // 就在数据库表的"goodsid"字段添加相等性查询条件，查找与传入商品ID匹配的退货记录，便于根据具体商品来查询其退货情况。 + + + // 对时间进行查询要求大于开始时间小于结束时间，当outportVo对象中的开始时间（outportVo.getStartTime()）不为空时，添加一个大于等于（ge）的查询条件， + // 在数据库表的"outputtime"字段（推测是退货时间字段）上，筛选出退货时间大于等于传入的开始时间的退货记录；同样，当结束时间（outportVo.getEndTime()）不为空时， + // 添加一个小于等于（le）的查询条件，筛选出退货时间小于等于传入的结束时间的退货记录，这样就能获取到处于指定时间范围内的商品退货信息，方便按时间区间进行数据查询和统计分析等操作。 + + + // 通过进货时间对商品进行排序，添加一个按照"outputtime"字段（退货时间）进行降序排序的条件，使得查询返回的退货记录按照退货时间从近到远的顺序排列， + // 这样在前端展示时，用户能先看到较新的退货记录，更符合一般的数据查看习惯，方便查看和分析近期的退货情况。 + + // 调用outportService的page方法，传入构建好的分页对象page和查询条件包装器queryWrapper，服务层会根据这些条件执行数据库查询操作， + // 获取符合条件的商品退货数据，并将数据填充到page对象中，例如设置page对象中的总记录数、当前页的记录列表等属性，最终返回填充好数据的page对象赋值给page1。 + + + // 获取查询结果中当前页的退货记录列表，方便后续对每条记录进行补充相关信息的操作，比如添加供应商名称、商品名称和规格等，使返回给前端的数据更加完整详细。 + + // 遍历当前页查询到的每条商品退货记录，为每条记录补充供应商名称、商品名称和规格等信息，使其展示的数据更加丰富全面，方便前端展示和业务查看使用。 + + // 通过providerService的getById方法，根据当前退货记录中的供应商ID（ouport.getProviderid()）从数据库中查询对应的供应商详细信息，获取到一个Provider对象（如果存在的话）。 + + + // 如果查询到了对应的供应商信息，将供应商的名称设置到当前退货记录（ouport）中，以便前端展示退货记录时能同时显示供应商名称，让数据更直观、完整。 + + // 通过goodsService的getById方法，依据当前退货记录中的商品ID（ouport.getGoodsid()）从数据库中查询对应的商品详细信息，获取到一个Goods对象（若存在的话）。 + + // 如果查询到了商品信息，将商品的名称设置到当前退货记录（ouport）中，方便前端展示退货记录时能呈现商品名称，使数据更具可读性。 + + // 同时将商品的规格信息也设置到当前退货记录（ouport）中，进一步丰富退货记录展示的数据内容，便于业务操作和查看详细情况。 + + + // 创建一个DataGridView对象，将查询得到的商品退货记录的总数量（通过page1.getTotal()获取）以及当前页补充完整信息后的退货记录列表（page1.getRecords()）进行封装， + // 最终返回给前端，使得前端能够按照分页逻辑展示商品退货信息，并且展示的数据包含了丰富的关联信息（供应商名称、商品名称和规格等），满足业务查看和操作的需求。 + + + /** + * 删除退货信息 + * @param id 要删除的退货记录的唯一标识符（通常是主键ID），由前端传入，通过这个ID来确定要从数据库中删除的具体退货记录。 + * @return 返回一个ResultObj类型的结果对象，ResultObj中定义了如DELETE_SUCCESS、DELETE_ERROR等枚举值，用于表示删除退货信息操作的成功或失败状态，方便前端根据返回结果进行相应处理或提示用户。 + */ + + + + // 调用outportService的removeById方法，传入要删除的退货记录的ID，服务层会根据这个ID在数据库中找到对应的退货记录并执行删除操作， + // 如果删除操作顺利完成则无异常抛出，若出现问题（比如存在关联数据、违反数据库约束等）则会抛出异常。 + + // 如果在删除退货信息过程中出现异常，打印异常堆栈信息（便于开发人员排查问题），然后返回表示删除操作失败的ResultObj.DELETE_ERROR结果对象给前端， + // 让前端知晓删除操作未成功，以便采取相应的提示或其他处理措施。 diff --git a/src/main/java/com/yeqifu/bus/controller/ProviderController.java b/src/main/java/com/yeqifu/bus/controller/ProviderController.java index 22c03cb..1e6aec5 100644 --- a/src/main/java/com/yeqifu/bus/controller/ProviderController.java +++ b/src/main/java/com/yeqifu/bus/controller/ProviderController.java @@ -115,3 +115,90 @@ public class ProviderController { } +// 假设所在类是一个Spring的RestController（通过 @RestController 注解标识，用于处理HTTP请求并返回JSON等格式的数据响应），用于处理与供应商（Provider）相关的各种业务请求。 + + + + // 注入一个实现了IService接口的服务层对象（这里假设名为providerService），用于调用服务层提供的与供应商相关的业务逻辑方法， + // 虽然代码中没有显示注入的语句，但在实际的Spring项目中，通常会通过依赖注入的方式获取该服务对象，比如使用 @Autowired 注解等方式进行注入。 + + // 根据传入的供应商查询条件（封装在ProviderVo对象中），加载所有符合条件的供应商信息，并进行分页返回。 + + // 1. 声明一个分页page对象 + // 创建一个IPage对象，用于实现分页功能，它接收当前页码（通过providerVo.getPage()获取，即从前端传入的页码信息）和每页显示的记录数量（通过providerVo.getLimit()获取）作为参数， + // 这样就确定了本次查询数据的分页范围，例如，当page为2且limit为10时，表示要获取第2页，每页显示10条供应商记录的那部分数据。 + + + // 2. 声明一个queryWrapper + // 创建一个QueryWrapper对象，用于构建查询条件，它可以方便地通过链式调用的方式添加各种查询条件，类似于构建SQL语句中的WHERE子句部分，用于筛选符合特定条件的供应商记录。 + + + // 根据供应商名称进行模糊查询，如果传入的供应商名称（通过providerVo.getProvidername()获取）不为空字符串（使用StringUtils.isNotBlank方法判断）， + // 则添加一个模糊查询条件，在数据库表中对应"providername"字段进行模糊匹配（匹配包含传入名称的记录），方便根据名称查找相关的供应商。 + + + // 根据联系人名称进行模糊查询，原理同上面的供应商名称查询，若传入的联系人名称（通过providerVo.getConnectionperson()获取）不为空，就在"connectionperson"字段上添加模糊查询条件， + // 以便筛选出符合联系人名称要求的供应商记录。 + + + // 根据电话号码进行模糊查询，同样判断传入的电话号码（通过providerVo.getPhone()获取）是否不为空，若不为空，则在"phone"字段添加模糊查询条件，实现按电话号码查找供应商的功能。 + + + // 调用服务层的page方法，传入构建好的分页对象page和查询条件包装器queryWrapper，服务层会根据这些条件执行数据库查询操作，获取符合条件的供应商数据，并将数据填充到page对象中， + // 例如设置page对象中的总记录数、当前页的记录列表等属性，以便后续返回分页数据。 + + + // 创建一个DataGridView对象，用于将分页查询得到的结果（总记录数通过page.getTotal()获取，当前页的记录列表通过page.getRecords()获取）进行封装， + // 最终返回给前端，方便前端进行分页数据展示等操作，DataGridView对象的具体结构和作用取决于项目中的自定义，一般是将数据整理成适合前端接收和展示的格式。 + + + + /** + * 添加一个供应商 + * @param providerVo 包含要添加的供应商信息的对象，通常是从前端传递过来，封装了供应商的各项属性值，比如名称、联系人、电话等信息。 + * @return 返回一个ResultObj类型的结果对象，用于表示添加操作的成功或失败状态，ResultObj中定义了如ADD_SUCCESS、ADD_ERROR等枚举值来明确表示不同的结果情况。 + */ + + // 调用服务层的save方法，将传入的包含供应商信息的providerVo对象传递给服务层，服务层会将这些信息保存到数据库中，实现添加供应商的功能， + // 例如将供应商的基本信息插入到对应的供应商表中，如果保存成功则无异常抛出，若保存过程中出现问题（如数据库连接异常、数据格式不符合要求等）则会抛出异常。 + + // 如果在保存供应商信息过程中出现异常，打印异常堆栈信息（方便开发人员排查问题），然后返回表示添加失败的ResultObj.ADD_ERROR结果对象给前端， + // 让前端知道添加操作没有成功，以便进行相应的提示或处理。 + + + /** + * 修改一个供应商 + * @param providerVo 包含要修改的供应商新信息的对象，从前端传入，里面的属性值是修改后的值，通过与数据库中已存在的供应商记录的主键等信息进行匹配来确定要修改的具体记录。 + * @return 返回一个ResultObj类型的结果对象，用于表示修改操作的成功或失败状态，ResultObj中定义了如UPDATE_SUCCESS、UPDATE_ERROR等枚举值来明确表示不同的结果情况。 + */ + + // 调用服务层的updateById方法，将传入的包含更新后供应商信息的providerVo对象传递给服务层，服务层会根据对象中的主键信息（通常是供应商的ID）， + // 在数据库中找到对应的供应商记录，并将其他属性值更新为providerVo对象中传入的新值，实现修改供应商信息的功能，如果更新成功则无异常抛出，若出现问题（如找不到对应记录、更新数据违反约束等）则会抛出异常。 + + // 如果在更新供应商信息过程中出现异常，打印异常堆栈信息（方便开发人员排查问题），然后返回表示修改失败的ResultObj.UPDATE_ERROR结果对象给前端， + // 让前端知道修改操作没有成功，以便进行相应的提示或处理。 + + + /** + * 删除一个供应商 + * @param id 要删除的供应商的唯一标识符（通常是主键ID），由前端传入，通过这个ID来确定要从数据库中删除的具体供应商记录。 + * @return 返回一个ResultObj类型的结果对象，用于表示删除操作的成功或失败状态，ResultObj中定义了如DELETE_SUCCESS、DELETE_ERROR等枚举值来明确表示不同的结果情况。 + */ + + + /** + * 加载所有可用的供应商 + * @return 返回一个DataGridView对象，里面包含了所有可用的供应商信息列表，用于在前端展示所有当前处于可用状态的供应商情况，方便后续业务操作选择使用。 + */ + + + + // 添加一个相等性查询条件，在数据库表中对应"available"字段，查询其值等于Constast.AVAILABLE_TRUE（这里Constast应该是项目中定义的一个常量类，AVAILABLE_TRUE表示可用状态的常量值）的供应商记录， + // 以此获取所有处于可用状态的供应商信息。 + + + // 调用服务层的list方法，传入构建好的查询条件包装器queryWrapper，服务层会根据这个条件执行数据库查询操作，获取所有符合可用状态条件的供应商数据，并返回一个包含这些供应商对象的列表。 + + + // 创建一个DataGridView对象，将查询得到的可用供应商列表进行封装，最终返回给前端，方便前端进行展示或者其他相关业务操作（比如在下拉框中展示可用供应商供用户选择等）。 + diff --git a/src/main/java/com/yeqifu/bus/controller/SalesController.java b/src/main/java/com/yeqifu/bus/controller/SalesController.java index 9e512f2..7c3c046 100644 --- a/src/main/java/com/yeqifu/bus/controller/SalesController.java +++ b/src/main/java/com/yeqifu/bus/controller/SalesController.java @@ -32,7 +32,7 @@ import java.util.List; */ @RestController @RequestMapping("/sales") -public class WSalesController { +public class SalesController { @Autowired private ISalesService salesService; diff --git a/src/main/java/com/yeqifu/bus/controller/SalesbackController.java b/src/main/java/com/yeqifu/bus/controller/SalesbackController.java index 05a1e77..e2b7b3b 100644 --- a/src/main/java/com/yeqifu/bus/controller/SalesbackController.java +++ b/src/main/java/com/yeqifu/bus/controller/SalesbackController.java @@ -114,3 +114,103 @@ public class SalesbackController { } + + +// SalesbackController类，使用了@RestController注解，表明它是Spring框架下用于构建RESTful API的控制器类，主要负责处理与商品销售退货（Salesback）相关的HTTP请求， +// 并将处理结果以合适的格式（如JSON）返回给客户端（通常是前端应用），在整个项目的前后端交互中起着桥梁的作用。同时，通过@RequestMapping("/salesback")注解， +// 为该控制器下所有的请求映射路径设置了公共前缀"/salesback"，便于对商品销售退货相关的接口进行统一管理和分类。 + + // 使用@Autowired注解自动注入ISalesbackService接口的实现类对象，通过这个服务对象，可以调用与商品销售退货相关的核心业务逻辑方法， + // 比如添加退货信息、分页查询销售退货记录以及删除销售退回信息等操作，具体的业务实现细节则在ISalesbackService接口对应的实现类中完成，这里只是进行调用触发相应的业务逻辑流程。 + + + // 通过@Autowired注解注入ICustomerService接口的实现类对象，用于获取客户相关的业务服务。在查询商品销售退货信息时，借助该服务根据客户ID查询客户的详细信息， + // 以便将客户姓名等相关信息补充到销售退货记录中，使返回给前端的数据更加完整，方便前端展示和业务操作时能呈现更全面的客户相关情况。 + + // 同样使用@Autowired注解注入IGoodsService接口的实现类对象，用于获取商品相关的业务服务。在处理销售退货记录查询结果时，通过该服务依据商品ID查询商品详情（如商品名称、规格等）， + // 然后将这些商品相关信息设置到销售退货记录中，进一步丰富返回给前端的数据内容，让前端能够展示更详细的商品相关信息，便于业务查看和分析销售退货情况。 + + /** + * 添加退货信息 + * @param id 进货单ID，这里可能用于关联到对应的销售记录，以明确此次销售退货操作是针对哪一笔销售业务进行的，作为确定退货操作关联业务的关键标识，由前端传入该参数。 + * @param number 退货数量，指定了此次销售退货中商品的具体数量，这个数量信息对于后续更新库存、统计退货数据以及涉及财务等相关业务操作都非常重要，同样由前端传入。 + * @param remark 备注，用于记录一些额外的关于此次销售退货的相关情况说明，例如退货原因（是商品质量问题、客户不满意还是其他原因等）、特殊的退货协商结果等内容，由前端传入该参数。 + * @return 返回一个ResultObj类型的结果对象，ResultObj中定义了诸如BACKINPORT_SUCCESS、BACKINPORT_ERROR等枚举值，用于明确表示添加销售退货信息操作的成功或失败状态， + * 方便前端根据接收到的返回结果进行相应的提示操作或者后续处理，比如提示用户添加成功或者告知添加失败的原因等。 + */ + + + // 调用salesbackService的addSalesback方法，将前端传入的进货单ID、退货数量以及备注信息传递过去，以此触发服务层中处理添加销售退货信息的业务逻辑， + // 该逻辑可能涉及到调整库存（将退货商品重新入库）、在数据库中插入销售退货记录、更新与销售退货相关的财务数据以及其他关联业务模块的数据交互等一系列复杂操作， + // 如果整个操作过程顺利完成，不会抛出异常；若在执行过程中出现问题（比如数据库插入失败、业务规则校验不通过等情况），则会抛出异常。 + + // 如果在添加销售退货信息的过程中出现异常，通过打印异常堆栈信息（这有助于开发人员在排查问题时了解详细的异常发生位置和原因）， + // 然后返回表示添加销售退货信息失败的ResultObj.BACKINPORT_ERROR结果对象给前端，使得前端能够知晓操作未成功，进而采取相应的提示告知用户或者其他补救措施等。 + + + /** + * 查询商品销售退货 + * @param salesbackVo 这是一个封装了查询条件的对象，通常包含分页相关信息（如页码、每页显示数量）以及其他筛选条件（如客户ID、商品ID、时间范围等），由前端传入， + * 方便后端统一处理各种不同的查询需求，根据这些条件从数据库中准确获取符合要求的商品销售退货记录。 + * @return 返回一个DataGridView对象，该对象一般是项目中自定义用于封装数据展示相关信息的，其中包含了查询到的商品销售退货记录的总数量以及具体的退货记录列表， + * 方便前端进行分页展示以及对数据进行进一步的处理和分析等操作。 + */ + + // 创建一个IPage对象，用于实现分页功能，通过传入从salesbackVo对象中获取的当前页码（salesbackVo.getPage()）和每页显示记录数量（salesbackVo.getLimit()）来确定分页范围， + // 例如，当页码为2且每页显示数量为10时，表示要获取第2页，每页显示10条商品销售退货记录的那部分数据，这样可以对大量的销售退货记录进行分页管理，提升前端展示效果以及用户查看数据的体验。 + + + // 创建一个QueryWrapper对象，用于构建查询条件，它类似于构建SQL语句中的WHERE子句部分，能够灵活地添加各种筛选条件，从而精确地查询出符合特定要求的商品销售退货记录。 + + + // 对客户进行查询，如果从salesbackVo对象中获取的客户ID（salesbackVo.getCustomerid()）不为空且不等于0，说明前端传入了客户筛选条件， + // 则添加一个相等性查询条件，在数据库表中对应"customerid"字段，查找与传入的客户ID相等的销售退货记录，以此实现按客户来筛选销售退货信息的功能，方便查看特定客户的销售退货情况。 + + + // 对商品进行查询，同理，当salesbackVo对象中获取的商品ID（salesbackVo.getGoodsid()）不为空且不等于0时，表明前端传入了商品筛选条件， + // 就在数据库表的"goodsid"字段添加相等性查询条件，查找与传入商品ID匹配的销售退货记录，便于根据具体商品来查询其销售退货情况，满足不同业务场景下对商品销售退货数据的查询需求。 + + // 对时间进行查询要求大于开始时间小于结束时间，当salesbackVo对象中的开始时间（salesbackVo.getStartTime()）不为空时，添加一个大于等于（ge）的查询条件， + // 在数据库表的"salesbacktime"字段（推测是商品销售退货时间字段）上，筛选出销售退货时间大于等于传入的开始时间的销售退货记录；同样，当结束时间（salesbackVo.getEndTime()）不为空时， + // 添加一个小于等于（le）的查询条件，筛选出销售退货时间小于等于传入的结束时间的销售退货记录，这样就能获取到处于指定时间范围内的商品销售退货信息，方便按时间区间进行数据查询、统计分析等操作。 + + + // 通过商品退货时间对商品进行排序，添加一个按照"salesbacktime"字段（商品销售退货时间）进行降序排序的条件，使得查询返回的销售退货记录按照退货时间从近到远的顺序排列， + // 这样在前端展示时，用户能先看到较新的销售退货记录，更符合一般的数据查看习惯，方便查看和分析近期的销售退货情况，有助于及时发现问题或者跟踪业务趋势。 + + // 调用salesbackService的page方法，传入构建好的分页对象page和查询条件包装器queryWrapper，服务层会根据这些条件执行数据库查询操作， + // 获取符合条件的商品销售退货数据，并将数据填充到page对象中，例如设置page对象中的总记录数、当前页的记录列表等属性，以便后续返回完整的分页数据信息。 + + + // 获取查询结果中当前页的销售退货记录列表，方便后续对每条记录进行补充相关信息的操作，比如添加客户姓名、商品名称和规格等，使返回给前端的数据更加丰富详细，更具业务价值。 + + + // 遍历当前页查询到的每条商品销售退货记录，为每条记录补充客户姓名、商品名称和规格等信息，使其展示的数据更加完整全面，方便前端展示以及业务查看和操作使用。 + + // 通过customerService的getById方法，根据当前销售退货记录中的客户ID（salesback.getCustomerid()）从数据库中查询对应的客户详细信息，获取到一个Customer对象（如果存在的话）。 + + // 如果查询到了对应的客户信息，将客户的姓名设置到当前销售退货记录（salesback）中，以便前端展示销售退货记录时能同时显示客户姓名，让数据更直观、完整，便于业务人员查看相关客户的退货情况。 + + // 通过goodsService的getById方法，依据当前销售退货记录中的商品ID（salesback.getGoodsid()）从数据库中查询对应的商品详细信息，获取到一个Goods对象（若存在的话）。 + + // 如果查询到了商品信息，将商品的名称设置到当前销售退货记录（salesback）中，方便前端展示销售退货记录时能呈现商品名称，使数据更具可读性，便于了解退货商品的具体情况。 + + // 同时将商品的规格信息也设置到当前销售退货记录（salesback）中，进一步丰富退货记录展示的数据内容，方便业务人员更详细地掌握退货商品的规格特点等信息。 + + + // 创建一个DataGridView对象，将查询得到的商品销售退货记录的总数量（通过page.getTotal()获取）以及当前页补充完整信息后的销售退货记录列表（page.getRecords()）进行封装， + // 最终返回给前端，使得前端能够按照分页逻辑展示商品销售退货信息，并且展示的数据包含了丰富的关联信息（客户姓名、商品名称和规格等），满足业务查看和操作的实际需求。 + + + /** + * 删除商品销售退回信息 + * @param id 要删除的商品销售退回记录的唯一标识符（通常是主键ID），由前端传入，通过这个ID来确定要从数据库中删除的具体销售退回记录。 + * @return 返回一个ResultObj类型的结果对象，ResultObj中定义了如DELETE_SUCCESS、DELETE_ERROR等枚举值，用于表示删除商品销售退回信息操作的成功或失败状态， + * 方便前端根据返回结果进行相应的处理或提示用户，比如提示用户删除成功或者告知删除失败的原因等。 + */ + + // 调用salesbackService的removeById方法，传入要删除的销售退回记录的ID，服务层会根据这个ID在数据库中找到对应的销售退回记录并执行删除操作， + // 如果删除操作顺利完成则无异常抛出，若出现问题（比如存在关联数据、违反数据库约束等情况）则会抛出异常。 + + // 如果在删除商品销售退回信息的过程中出现异常，打印异常堆栈信息（便于开发人员排查问题根源），然后返回表示删除操作失败的ResultObj.DELETE_ERROR结果对象给前端， + // 让前端知晓删除操作未成功，以便采取相应的提示或者其他处理措施，比如告知用户删除失败，可尝试再次操作等。