Почему я и поддерживаю, и выступаю против интерфейса, использующего Map для передачи данных?

Java
Почему я и поддерживаю, и выступаю против интерфейса, использующего Map для передачи данных?

1 Бросать кирпичи, чтобы привлечь нефрит

Давайте сначала посмотрим на очень простой бизнес-код

  Map<String, Object> map = service.getDataByName("悟空GoKu");
  Long userId = (Long)map.get("userId");
  String phone = (String)map.get("phone");

Каждый раз, когда я пишу такую ​​карту, чтобы получить возвращаемые данные, я всегда чувствую себя очень неловко.

  1. карта как бездонная яма, не узнаешь что внутри если не посмотреть код провайдера放了什么key.
  2. После того, как вы получите данные, вы должны сделать это самостоятельно强转Да ладно, это немного хлопотно.
  3. У этой штуки есть потенциал类型转换异常发生.

2 Параметры запроса Запрос

Первое, что нужно убедиться, это использование карты для передачи параметров (внутренний интерфейс HTTP-запроса) действительно方便, вам не нужно определять дополнительный класс, вы можете подключить к нему любые данные, которые вы хотите, как в следующем примере, вам не нужно определять класс RequestVo для каждого интерфейса, и унифицированный прием карты

@PostMapping(value = "/map")
public ApiResponse testMap(@RequestBody Map<String, Object> map) {
    //获取map中的数据
    Long userId = (Long)map.get("userId");
    String phone = (String)map.get("phone");
    //业务代码...
    return ApiResponse.ok();
}

Как упоминалось выше, мне не нравится получать данные таким образом, но я также не люблю определять класс для их получения, потому что это вызовет类数量激增, возможно, интерфейс запроса должен создать соответствующий класс запроса.

Некоторые люди говорят, что без определения его как класса нельзя использовать некоторые дополнительные функции:

  1. Аннотации документов, такие как swagger, не совсем совместимы.

Я не хочу использовать swagger, слишком навязчивый код, стиль и отображение каталогов также общие, в документации по интерфейсу рекомендуется использовать yapi с открытым исходным кодом.

Swagger иногда очень удобен, при добавлении параметров код обновляется одновременно с документацией, поэтому нет необходимости вести документацию, но я все равно не люблю связывать документацию с кодом.

  1. Нельзя использовать аннотацию проверки валидатора.

Мне все же нравится писать логику проверки в контроллере, логика понятнее.

Оригинальные аннотации не обязательно подходят для каких-то сложных верификаций, не нужно ли дорабатывать аннотации и возвращаться к проблеме размножения классов

Говоря о карте, очень неудобно получать данные типа map.get(key), но мы можем封装请求Какие, Например, предыдущая статья Когда технический руководитель сказал разработать интерфейс RESTful, я отказался.>> Упомянутый ApiRequest.


public class ApiRequest implements Serializable {
  //....省略部分代码    
  private Map<String, Object> data;  //通过拦截器处理后请求参数已存放在这里
  public Long getDataParamAsLong(String name, Long defaultValue) {
      Long i = defaultValue;
      try{
          i = StringUtils.isNotEmpty(getDataParamAsString(name)) ? 
              Long.valueOf(getDataParamAsString(name)) : defaultValue;
      }catch (Exception e){
          e.printStackTrace();
      }
      return i;
  }
}

@PostMapping(value = "/test")
public ApiResponse test(ApiRequest apiRequest) {
    Long userId = apiRequest.getDataParamAsLong("userId", 0L);
    //省略部分代码....
    ApiResponse response = ApiResponse.ok()
    return response;
}

вот уже面向json编程вместо объектно-ориентированного подхода прошлого.

3 Параметры ответа Ответ

Что касается возвращаемых данных, я обычно получаю служебные данные на уровне контроллера, а затем обрабатываю данные в соответствии с бизнес-требованиями (модификация структуры, интеграция данных) и, наконец, использую карту для интеграции, а затем отвечаю, чтобы предоставить интерфейсу подходящее решение. структура.而不是数据库查到什么就整个类对象返回.

В настоящее время я также определяю класс ReponseVo для инкапсуляции некоторых возвращаемых данных и, наконец, возвращаю их во внешний интерфейс.

Вы непоследовательны, вы сказали раньше, что не должны быть объектно-ориентированными.

В некоторых сценариях, в основном рассматриваемых здесь, данные, возвращаемые несколькими интерфейсами, абсолютно одинаковы и могут совместно использоваться. Некоторые разработчики приложений будут полагаться на интерфейс серверной части для определения своих собственных моделей.Подобные данные потребуют, чтобы поля, возвращаемые серверной частью, имели одинаковое имя и структуру, чтобы они могли совместно использовать модель.

Это... На самом деле, они могут определять свои собственные модели вместо完全依赖Именование полей Backstage.

4 передача данных сервисного уровня

Внешний/мобильный интерфейс http запрашивает наш интерфейс шлюза, вот что мы服务端之间Вызов удаленного/локального метода также можно понимать как вызов метода сервисного уровня. Если параметров несколько, вам нужно инкапсулировать DTO, и здесь лучше не использовать карту.

  1. Мы не можем написать документ для поддержки этого интерфейса.
  2. 数据反序列化问题（划重点）.

Если метод использует внутренний кеш и возвращается после десериализации с помощью json, легко вызвать исключение для вызывающей стороны.


//set 
@PostMapping(value = "/setData")
public ApiResponse setData(ApiRequest request) {
    //省略部分代码...
    Map<String, Object> map = new HashMap<>();
    map.put("id", 123L);
    map.put("name", "悟空GoKu");
    stringRedisTemplate.set("KEY_GOKU", JsonUtil.toJsonString(map));
    return ApiResponse.ok();
}
//get 
@PostMapping(value = "/getData")
public ApiResponse getData(ApiRequest request) {
    Map<String, Object> map = stringRedisTemplate.get("KEY_GOKU", Map.class);
    Long id = (Long)map.get("id");  //会发生异常ClassCastException
    return ApiResponse.ok();
}

Когда json десериализует карту, если исходное целочисленное значение меньше максимального значения int,反序列化后原本为 Long 类型的字段，会变为 Integer 类型.

Преимущество сериализации json в том, что она более удобочитаема. но没有携带类型信息, десериализация может быть выполнена точно только в том случае, если предоставлена ​​точная информация о типе, что особенно часто вызывает проблемы в сети.

5 Резюме

Наконец, несколько предложений, резюмирующих точку зрения этой статьи,仅代表个人看法

  1. Интерфейс внешнего/мобильного запроса, ориентированный на программирование json, использует карту для передачи данных, возвращаемые данные некоторых интерфейсов могут быть определены как класс VO.
  2. Для вызовов методов между серверами, если имеется несколько параметров, необходимо определить класс DTO для передачи данных.
  3. Чрезвычайно важно иметь хорошо видимый интерфейсный документ для совместной отладки фронтенда и бэкенда, при написании кода не забывайте писать документ.

Особенно хочу диссить тех back-end разработчиков, которые не пишут комментарии в полях, добавляют поля в код и не синхронизируются с документом ххх

Категории