后端应有的良好的开发习惯，你有吗？

目录

• 1.合理拆分目录结构
• 2.DTO与VO
• 3.封装工具类及业务方法
• 4.集合操作不要返回null
• 5.不要在BService中调用ADao
• 6.@ConfigurationProperties 与 @Value 使用场景
• 7.try/catch 内部代码抽成一个方法

 

---

回到顶部

1.合理拆分目录结构

很多人受传统MVC模式影响，只要新建项目，就是controller、service、dao、mapper、entity库库建包，

若是小项目，业务不多，倒也说的过去，但若项目很大，那么就如同controller包下就会有上百个类，很难区分所属的业务，对于后期的维护也是比较困难，因为寻找代码也是一件麻烦又费时的事情。

因此，按照业务分模块，在模块内部再按MVC分层，就显得尤为重要，如下图（仅供参考，可根据实际情况继续拆分）

          

需要注意的是，这里都进行了分目录，故对于包扫描和xml文件路径需要同步更新（这里以SpringBoot项目为例）：

配置mybatis的xml位置

mybatis.mapperLocations = classpath*:mapper/*/*Mapper.xml

在启动类配置包扫描

@MapperScan(basePackages = {"com.zxh.modules.*.dao"})

 

回到顶部

2.DTO与VO

DTO与VO没有本质上的区别，实际上都是POJO，但DTO是表示从数据库取出的数据对象，而VO是返回给前端的数据对象，当有些信息从数据库查询出来但不能返回给前端时两者就起到了很好的作用。

说到这里，对于请求和响应的参数，就值得一提。当在方法中参数很多时，最好将参数封装为对象进行后续的传递，否则后续参数发生变更时，涉及多个地方需要修改，而参数过多，看起来也不优雅。

public void getList(String name, Integer age, String sex, String region, String birth) {
        //进行业务处理
    }

上述参数就比较多，实际上只要形参超过3个就应该封装。便于区分是请求参数还是响应参数，故对请求参数对象添加后缀Request，而响应参数添加后缀VO即可。封装如下：

    public void getList(UserRequest userRequest) {
        //进行业务处理
    }

如请求对象UserRequest，响应对象UserVO。

 

回到顶部

3.封装工具类及业务方法

对于工具类，虽然很多内置的jar中已包含太多的工具类，但有时并不适用或者说为了统一代码规范，就使用自定义封装的工具类，在工具类中调用jar中的工具类也未尝不是一种方式。

对于业务方法，很多人会在一个方法中写处理某一业务逻辑的全部代码，而这个方法的代码可能高达几千行甚至上万行，对于日后的维护是非常不利的。因此，可以将代码中许多小业务的代码抽成一个或多个方法，然后在原方法中进行调用，整个代码就会显得非常的简洁，阅读起来也非常的清晰明了。

 

回到顶部

4.集合操作不要返回null

很多时候对于集合的操作，若查询不到值就返回null，在使用的地方还需要进行非空的判断， 否则会出现空指针异常。此时建议无数据返回空集合，然后在调用的地方无需强制性判断，只需根据需要判断即可。

当然在判断是否为null或空集合时，可以使用最简单的代码

public static Boolean isNotEmpty(List list) {
    return list != null && list.size()>0;
}

其实也可以使用自带的非空判断

    public static Boolean isNotEmpty(Collection<?> collection) {
        return CollectionUtils.isEmpty(collection);
    }

这里的工具类导入的包是 org.springframework.util.CollectionUtils 。

 

回到顶部

5.不要在BService中调用ADao

大多时候为了方便，很多人喜欢直接在BService中调用ADao，对其进行数据操作，比如在OrderServiceImpl中直接注入UserDao去查询用户信息，这是不可取的。采用MVC架构就是要实现高内聚低耦合，若这样乱调用，就使得代码混乱并冗余。（说明：ADao即为AMapper，叫法不同如而已）

好的做法是OrderServiceImpl中直接注入UserService，通过在UserService中添加方法然后在UserServiceImpl中实现并去调用UserDao。

因此，必须遵从BService  ->  AService  ->  ADao 的MVC原则。

 

回到顶部

6.@ConfigurationProperties 与 @Value 使用场景

1）区别

两种注解斗能够读取配置文件中属性并绑定到JavaBean中，但用法有所不同。

不同点	@ConfigurationProperties	@Value
使用位置	标注在JavaBean的类名上	标注在JavaBean的属性上
功能	用于批量绑定配置文件中的配置	单个的指定需要绑定的位置，绑定粒度更小
松散绑定支持	支持。例如实体类Person中有一个属性为username，那么配置文件中的属性名支持以下写法：person.username、person_name、person.user_name、PERSON_USER_NAME	不支持
复杂类型封装	支持所有类型的封装。例如Map、List、Set以及对象等	只支持基本数据类型的封装。例如：字符串、布尔值、整数等类型
应用场景	专门编写一个JavaBean来和配置文件进行映射时使用	获取配置文件中的某项值时使用

2）用法实战

在配置文件application.properties中配置

person.name=zhangsan
person.age=20
person.chinaName=张三

使用@ConfigurationProperties，需新建实体类

package com.zxh.test.entity;

import lombok.Data;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.stereotype.Component;

@Component
@ConfigurationProperties(prefix = "person")
@Data
public class Person {

    private String name;

    private Integer age;

    private String chinaName;
}

注入对象进行使用

    @Autowired
    private Person person;

    @Test
    public void test() {
        System.out.println(person);
    }

打印结果如下：

?

1	Person(name=zhangsan, age=20, chinaName=张三)

 

使用@Value，单个注入即可

    @Value("${person.name}")
    private String personName;

    @Value("${person.age}")
    private Integer personAge;

    @Value("${person.chinaName}")
    private String personChinaName;

    @Test
    public void test2() {
        System.out.println(personName);
        System.out.println(personAge);
        System.out.println(personChinaName);
    }

可以看的出来，如果注入的值比较多，则使用@ConfigurationProperties会比@Value方便很多，更推荐使用@ConfigurationProperties。

 

回到顶部

7.try/catch 内部代码抽成一个方法

try/catch代码有时会干扰我们阅读核心的代码逻辑，当里面的逻辑代码过长，阅读起来非常的困难，这时就可以把try/catch内部主逻辑抽离成一个单独的方法，不过需要根据实际情况进行拆分。

 

 

将持续更新中，你还有更好的习惯可以在评论区留言。

参考文章：https://www.cnblogs.com/csnjava/p/16731456.html