如何将客户端与服务器端分离？

Question

当涉及到SPA客户端应用程序和API / REST后端时，我正在努力解决松散耦合的问题。每个人似乎都认为紧密耦合前端和后端代码是不好的做法，我理解为什么。

但我的问题是，在服务器和客户端应用程序需要相同模型并可以对这些模型进行更改的情况下，如何将它们松散耦合？我想你必须重复模型声明的代码（这也是不好的做法）或让客户端代码了解后端的模型结构。

例如，假设我在客户端上编写object.someprop = 'some value'之类的代码，但someprop不再是属性或在服务器上更新。然后我必须更新客户端，我的理解属于紧密耦合的类别。

似乎即使在客户端编写类似object.someprop的内容也是错误的。但如果我不知道如何允许用户与数据交互？

有人可以给我一些关于这里应该发生什么的信息吗？

Answer 1

客户端将依赖于服务器提供的接口，例如REST接口，graphql，flatbuffer等。此接口可视为服务器和客户端同意的合同。这确实意味着提供的数据结构，并且是耦合的一种形式。因此需要清楚地描述/定义API并制定版本控制和废弃的策略 - 至少如果有多个客户端使用API​​并且客户端和服务器无法同时发布。对于只有服务器生成的html客户端的基本Web应用程序，您可以跳过API版本控制。

所以这看起来似乎是乍看之下的紧密耦合，但并非必须如此。客户端和服务器可能使用或不使用相同的语言/数据表示。他们所同意的只是访问方式和传输格式。通常，传输格式还有其他转换，例如JSON到javascript对象。在这个例子中，客户端可以随意使用JSON做任何事情。它可以使用所有数据或仅使用单个属性。所有这些都与服务器无关。类似地，客户端不关心服务器如何创建此JSON字符串。它可以在golang中实现，并且具有完全不同的内部表示 - 客户端不会知道。由于服务合同仅描述了接口以及由此产生的服务器/客户端实现自由度，因此可以认为耦合是松散的（足够）。

在您的具体示例中，您似乎在描述在服务器和客户端上都使用javascript的情况，并且您想知道是否可以使用相同的代码库（至少表示对象）。您可以为接口部分执行此操作（请查看graphql approach），但通常最好在服务器上使用单独的内部对象类型，因为通常您会发现需要添加其他属性，内部处理的引用目的或给客户不安全的目的（想想密码，隐私相关数据，秘密等）。

Answer 2

您必须在更广泛的意义上区分松散耦合和继承，而不仅仅是子类化。当您需要完全相同的模型以供客户端和服务器重用时 - 这是完全正常且非常正常的事情。您只需引入共享程序集（有时也称为核心）并定义常见内容（包括假设在客户端/服务器必需项方面具有不同实现的抽象类）。除非你不打算将接口与实现分开，否则这不会紧密耦合，好吗？松散耦合完全取决于接口/ adtract clasess而不是具体的实现：你可以分享一些常见的实现，但即使这样，客户端和服务器通常也不应该依赖它们;所有功能的输入/输出必须是实现 - 不知道。