数据库实体与业务逻辑的分离：子栏目获取方法的最佳位置
项目开发中，代码结构和职责划分至关重要。本文探讨一个常见问题：获取子栏目方法，究竟应该放在实体类（Entity）还是服务类（Service）？
有开发者将此方法置于Cat.Java实体类中，代码如下：
package com.test.blog.pojo.po; import java.util.List; import com.baomidou.mybatisplus.annotation.IdType; import com.baomidou.mybatisplus.annotation.TableId; import com.baomidou.mybatisplus.core.conditions.query.QueryWrapper; import com.baomidou.mybatisplus.extension.activerecord.Model; import lombok.AllArgsConstructor; import lombok.Data; import lombok.NoArgsConstructor; /** * 栏目实体类 */ @Data @NoArgsConstructor @AllArgsConstructor public class Cat extends Model<Cat> { @TableId(type = IdType.AUTO) private Integer catid; private String catname; private Integer pid; private String title; private String description; private Integer sortid; private Short pagesize; public List<Cat> getChildren() { QueryWrapper<Cat> queryWrapper = new QueryWrapper<>(); queryWrapper.eq("pid", this.catid); List<Cat> list = this.selectList(queryWrapper); // 注意这里调用了this.selectList return list; } }
这两种方案各有优劣：
方案一：Entity层（面向对象方法）
将方法置于Cat实体类中，符合面向对象设计原则，使实体类更完整地表达其自身行为。 然而，这依赖于实体类具备数据库访问能力，增加了实体类的耦合度。
方案二：Service层（面向接口方法）
将方法置于Service层，遵循了服务层处理业务逻辑的原则，保持实体类纯粹的数据模型。这更利于代码维护和测试，也避免了因代码生成覆盖自定义方法的问题。 Service层可以依赖于DAO层或Repository层进行数据库操作。
最终选择：
对于小型项目或个人项目，选择Entity层可能更简洁。但对于团队项目，特别是采用代码生成工具（如MyBatis-Plus）的项目，强烈建议将获取子栏目方法放在Service层。这可以有效避免代码覆盖问题，并保持实体类与业务逻辑的清晰分离，提高代码的可维护性和可扩展性。 Service层方法可以清晰地表达业务意图，并更容易进行单元测试。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
THE END
