MassTransit消息合同微服务方法

发布于 2025-02-10 23:08:18 字数 150 浏览 1 评论 0原文

我想使用MassTransit(首次)创建一个简单的微服务项目。我关心的是消息合​​同。我不喜欢微服务中的共享项目,但是MassTransit迫使我在一个共享项目中进行按摩或在单独的项目中创建主题,但名称空间必须相同。您如何处理此要求?您是创建共享项目还是创建消息,例如而无需命名空间?

I want to create a simple microservices project using MassTransit (for the first time). My concern is about message contracts. I'm not a fan of shared projects in microservices but MassTransit forces me to put massages in one shared project or create theme in separate projects but namespace must be the same. How do you handle this requirement? Do you create shared project or create messages e.g. without a namespace?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

南城旧梦 2025-02-17 23:08:18

两种方法都可以使用,这是让您最舒适的事情。

如果您创建一个共享的nuget,并确保您的合同已进化以保持向后兼容性,则无需项目来升级Nuget。只要进行任何合同的更改以新的属性是可选的/可确定的,并且消费者可以适当处理丢失的属性,就没有疑虑。

每个项目中的单独合同基本上必须以相同的方式进行管理,直到现在您才必须更新多个项目以使用任何其他属性。也许没什么大不了的,但是剪切并不是很有趣。

在我看来,命名空间的关注是荒谬的。这是文件中的字符串。我不明白为什么人们会为此而努力,但是如果MassTransit只使用了消息类型标识符的类名称,那将是一团糟。

Either approach works, it's whatever makes you most comfortable.

If you create a shared NuGet, and ensure your contracts are evolved to retain backwards compatibility, there is no need for projects to upgrade the NuGet. So long as any contract changes are made in a way that new properties are optional/nullable, and the consumer handles missing properties appropriately, there are no concerns.

Separate contracts in each project essentially have to be managed the same way, only now you have to update multiple projects to use any of the additional properties. Maybe not a big deal, but cut-and-paste isn't exactly fun.

The namespace concern is just ridiculous in my opinion. It's a string, in a file. I don't understand why people get worked up over it, but if MassTransit only used class name for a message type identifier, it would be a mess.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文