Является ли принятие доменных объектов в качестве полезных данных запроса в grpc анти-паттерном? - PullRequest
0 голосов
/ 02 ноября 2019

У меня есть простой сервис, который содержит определения сообщений, такие как

message BrandAttribute {
 option (gorm.opts) = {
    ormable: true
 };
 atlas.rpc.Identifier id = 1 [(gorm.field).tag = {type: "serial" primary_key: true}];
 string attribute_key = 2;
 string attribute_value = 3;
 atlas.rpc.Identifier brand_id = 4 [(gorm.field).tag = {not_null: true}];
 Status status = 5;
}

message Brand {
 option (gorm.opts) = {
    ormable: true
 };
 atlas.rpc.Identifier id = 1 [(gorm.field).tag = {type: "serial" primary_key: true}];
 atlas.rpc.Identifier external_id = 2 [(gorm.field).tag = {type: "text" unique: true}];
 string name = 3;
 string description = 4;
 string keywords = 5;
 string meta_keywords = 6;
 string meta_description = 7;
 repeated BrandAttribute brand_attributes = 8 [(gorm.field).has_many.foreignkey = "brand_id", (gorm.field).has_many.association_foreignkey = "id"];
 Status status = 9;
}

Я определил сервисы для реализации операций CRUD поверх вышеуказанного объекта, но эти сервисы принимают саму Бренд в качестве полезной нагрузки запроса (параметр) для операций создания / обновления, этот подход правильный? если это не то, что является лучшим способом достичь этого. Кроме того, если я хочу использовать JDBC для настойчивости, мне придется самому украшать сущности, которые протокол не допускает в файлах определения protobuf, как мне этого добиться?

1 Ответ

1 голос
/ 08 ноября 2019

Потенциальная проблема с использованием Brand в качестве запроса заключается в том, что если вам когда-либо понадобится добавить дополнительную информацию к запросу, но вы не хотите добавлять ее в Brand, вы застрянете. Рекомендуется для каждого метода обслуживания всегда определять для него выделенные типы запросов и ответов. Для вашего случая вы должны сделать сообщения CreateRequest, UpdateRequest и т. Д., Которые содержат Brand.

...