我正在将旧版应用程序(微服务和整体软件的一部分)迁移到使用GRPC的过程中。整个代码库当前位于GO中。
我已经开始对消息建模,它们看起来与我在应用程序代码中使用的结构非常相似。我两次定义相同的对象似乎很奇怪,但是将消息对象用作核心结构也很奇怪。似乎我将有大量内存密集型数据封送处理。以下是消息和结构的示例,以及它们之间的相似程度。
在决定如何对邮件进行建模方面,是否有任何建议/最佳做法?它们是否应该与我的核心结构保持一致?我是否应该不在乎从Golang结构到消息的所有编组?
如果我问的是一个基本问题,请原谅我,因为我对协议缓冲区和GRPC非常陌生。
消息原型定义:
message Profile {
string UID = 1;
string ContactEmail = 2;
google.protobuf.Timestamp DateOfBirth = 3;
float WeightInKilos = 4;
string Gender = 5;
string Unit = 6;
string CurrentStatus = 7;
string Country = 8;
string ExperienceType = 9;
google.protobuf.Timestamp DateJoined = 10;
repeated Ability Abilities = 11;
repeated Role Roles = 12;
repeated TermsAndConditionsAcceptance TermsAndConditionsAcceptances = 13;
string TimeZone = 14;
repeated BaselineTestResults BaselineTests =15;
//Excluded UpdatedDate as other domains shouldn't need it
string FirstName =16;
string LastName =17;
string DisplayName = 18;
string State = 19;
repeated google.protobuf.Any Preferences = 20;
Thresholds Thresholds = 21;
string StripeCustomerID = 22;
}
结构Def:
type Profile struct {
UID string `json:"UID" firestore:"UID"`
ContactEmail string `json:"ContactEmail,omitempty" firestore:"ContactEmail"`
DateOfBirth time.Time `json:"DateOfBirth,omitempty" firestore:"DateOfBirth"`
WeightInKilos float64 `json:"WeightInKilos,omitempty" firestore:"WeightInKilos"`
Gender string `json:"Gender,omitempty" firestore:"Gender"`
Unit string `json:"Unit,omitempty" firestore:"Unit"`
CurrentStatus string `json:"CurrentStatus,omitempty" firestore:"CurrentStatus"`
Country string `json:"Country,omitempty" firestore:"Country"`
ExperienceType string `json:"ExperienceType,omitempty" firestore:"ExperienceType"`
DateJoined time.Time `json:"DateJoined,omitempty" firestore:"DateJoined"`
Abilities []Ability `json:"Abilities,omitempty" firestore:"Abilities"`
Goals Goals `json:"Goals,omitempty" firestore:"Goals"`
Roles []Role `json:"Roles,omitempty" firestore:"Roles"`
TermsAndConditionsAcceptances []TermsAndConditionsAcceptance `json:"TermsAndConditionsAcceptances,omitempty" firestore:"TermsAndConditionsAcceptances"`
TimeZone string `json:"TimeZone,omitempty" firestore:"TimeZone"`
BaselineTests []BaselineTestResults `json:"BaselineTests,omitempty" firestore:"BaselineTests"`
UpdatedDate time.Time `json:"UpdatedDate,omitempty" firestore:"UpdatedDate"`
FirstName *string `json:"FirstName,omitempty" firestore:"FirstName"`
LastName string `json:"LastName,omitempty" firestore:"LastName"`
DisplayName string `json:"DisplayName,omitempty" firestore:"DisplayName"`
State string `json:"State"`
Preferences map[string]interface{} `json:"Preferences"`
Thresholds Thresholds `json:"Thresholds"`
StripeCustomerID string `json:"-"` //Tells it to ignore exporting
}
虽然是一个非常基本的问题,但也是一个很好的问题。人们通常会跳过它,并且随着它的增长而不得不在以后的代码库中苦苦挣扎。
当然,在消息中完全需要处理请求的数据的情况下,将消息用作核心结构将很有帮助。但在需要从其他来源获取数据的情况下,这将无济于事。
通常,消息数据是由边界层/控制器处理的,它进一步使用多种服务来创建响应。因此,服务层/逻辑层独立于控制器层,消息结构和核心结构也应如此。
始终尝试减少层之间的耦合,以使它们可重复使用。
因此,如果您有一个处理数据库的层,那么您也应该为此使用单独的结构。
本文收集自互联网,转载请注明来源。
如有侵权,请联系 [email protected] 删除。
我来说两句