Должен ли я преобразовать сообщение gRPC protobuf в DTO? - Лучшая практика

В последнее время я начал использовать сообщения gRPC для взаимодействия с микросервисами. До сих пор я использовал REST API с DTO, которые продолжали развязывать и инкапсулировать в самом коде.

Теперь, когда я использую gRPC protobuf msgs, я начал задаваться вопросом, какая оболочка будет здесь лучшей практикой - размышляя об этом вслух, я бы сказал, что при получении сообщения в точке входа приложения лучше всего было бы преобразовать его в DTO, чтобы продолжить отделение от сообщений gRPC protobuff и самого кода, с другой точки зрения - я просто преобразовываю объект в объект и задаюсь вопросом, являются ли эти накладные расходы обязательными / обязательными

Ждем ваших мыслей по этому поводу :)


java grpc design-patterns protobuf-java
person USer22999299    schedule 17.09.2020    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Ну, это зависит от ваших требований и от того, насколько развязанным должен быть ваш сервис (в долгосрочной перспективе). Насколько мне известно, некоторые сервисы/люди даже склонны записывать прототип непосредственно в базу данных (т.е. в виде прото-строки/байтовой строки или байта[]), чтобы уменьшить накладные расходы на сопоставление и по другим причинам. наверное.

Сказав это, лично я считаю, что модель предметной области и объекты передачи данных (сообщение Protobuf) должны быть максимально разделены. Поэтому лучше иметь дополнительное сопоставление для вашего запроса и ответа, которое поможет вам для будущих изменений в определениях IDL или proto.

Если вы полностью полагаетесь на реализацию уровня ресурсов/API, которой в вашем случае является gRPC, даже небольшое обновление библиотеки может сломать что-то, и было бы хлопотно просмотреть все места, где использовалась прототипная модель.

Кроме того, это поможет вам легко адаптироваться к изменениям, например, если ваша система решит полностью полагаться на другую схему API.

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

person Paritosh Bhattarai    schedule 21.09.2020