Thrift 中缺少“对象”是不是很尴尬？ [关闭]

Question

注意：我知道问题标题不是最理想的。随时改进。

Thrift 启用序列化以及 RPC。但是，与 COM 或 CORBA 或 ZeroC ICE 等系统不同，...它确实没有以多态方式具有远程对象或远程接口的概念，因此在 Thrift 基础结构中定义的所有服务都只是函数集合。

Thrift Features

Thrifts Non-Features 将多态性状态（接口？）作为一个足够公平的非目标，但是 ...

作为一名使用自然使用对象的语言的程序员，我可以拥有返回其他对象（或接口引用）的函数，而不仅仅是结构，这似乎有点尴尬，因为这意味着所有“节俭服务中的对象”功能必须由另外将句柄作为输入参数的函数提供，以定义正在操作的内容——有点像在 C 中做 OO :-)

想象一下对文件进行操作的 thrift 服务。它的接口看起来更像 C 的接口（@98​​7654322@ 等），而不是我们今天在 C++、C# 甚至 Python 中使用的接口。

当然可以用目标语言编写额外的包装器，但你没有 Thrift 框架的任何支持，所以这就是我所说的“尴尬”。

换一种说法：回到远程服务级别的纯过程界面是否有问题？

再给一个转折点：即使我使用 Jenkins 的 REST 接口，我也觉得基于 URL 的接口有点“OO”，因为我通过 URL 名称访问作业对象，然后指定对它们的操作通过 GET 参数。也就是说，对我来说，基于字符串的 REST 方法似乎可以比纯粹的过程接口更自然地捕获对资源（对象或接口，如果你喜欢）的操作。 完全可以 Thrift 将其定义为超出范围，但最好知道用户是否认为这是一件值得注意的事情。

这是活跃的 Thrift 用户的问题：我上面描述的问题是日常使用中的实际问题吗？这完全是一个观察到的问题吗？

这是 SOA 的一般“问题”吗？

Answer 1

我的印象是，您以错误的方式混合概念，然后试图从中得出结论。

• RPC 只不过是一个remote procedure call。这意味着：调用一段远程代码，传递一些参数并获得一些结果。就这样。如何解释这些数据是完全不同的事情。

• 在 OOP 上下文中，每个 method call（包括 RPC，但不限于）是一个带有额外隐藏参数的过程/函数调用，通常称为 this 或 @987654332 @。对象与非 OOP 代码的真正区别在于能够进行信息隐藏、派生类和覆盖方法，以及其他一些不错的东西。在幕后一切都只是数据，当您必须将对象反序列化为例如数据库 - 在大多数情况下，您将使用某种 ORM 来完成该任务。 RPC 机制位于等效平面上。 COM 或 CORBA 等框架在幕后做了什么is nothing else, they just hide it better from you。

• 至少对于 COM，您不是在处理对象。您正在与接口进行交互，这些接口通常实现为对象。很难判断一个特定的接口是否是对象的一部分，或者它是由aggregation 或组合添加的。甚至相反的情况也是如此：可能是这样的，两个原本不相关的接口可能由于某种原因由同一个对象实例实现。接口与服务的共同点比与对象的共同点要多。

• SOA 不限于 RPC。例如，REST-based 接口不被很多人认为是 RPC（尽管有人可能会争论这一点），并且不提供任何名副其实的对象，但您可以使用 REST 进行 SOA。当然，SOA 也不限于 COM 或 CORBA 环境，也不限于 SOAP 或 XML-RPC 接口。 SOA 主要是关于服务（因此得名），而不是对象。一句话概括，RPC、OOP、SOA是不同的概念，相互比较就是所谓的category mistake。

• 服务器和客户端代码如何表示您的数据取决于所使用的系统和目标语言的特征。不要让自己对 IDL 实体的命名感到困惑 - IDL 中的 struct 不一定是代码中的 struct。例如，使用 Thrift 和 C# 作为目标语言，您会得到从 struct 生成的简洁的 partial class-es，可以通过一些手动编写的代码轻松扩展。这可能与另一种目标语言（例如纯 C 或 the Go language）和其他系统（如 Protobuf、Avro 或您选择的 REST 客户端）不同。