我在一家公司工作，开发一个使用 Delphi 10 Seattle (VCL) 制作的大型应用程序，使用直接连接到 Oracle 数据库服务器（2 层）。
mormot一位专家建议使用（或其他库/组件）迁移到 3 层架构。
他的一个论点是，新架构（3 层）将提供更高的性能（交换数据的时间），因为 https 比直接 oracle 连接更快，并且 json 对象更轻（其余部分不使用缓存策略），我们之后可以制作网络客户端。
我不明白：
亲切地
在任何 n 层框架的上下文中，通过 REST 解决方案进行远程 SOA 访问可能会带来性能优势。
mORMot文档试图介绍所有这些概念（SOA、REST、MVC、n-Tier、Clean Architecture、DDD...），然后只讨论性能影响。不要孤立地使用文档语句。考虑整体情况和用例。
为什么 https 比 oracle 连接协议快？
HTTPS在 se中并不“更快” 。这意味着它对于远程连接可能更有效，尤其是通过 Internet。
Oracle Connection 协议设计为在本地网络上运行，而 HTTP 是一个查询/应答模型。
Oracle 协议的主要优点是它比简单的查询/回答模型更完整（复杂？）：它可以与 Oracle 服务器对话以缓存语句和数据，它可以有实时通知，它可以准备准备好被编码的二进制形式的数据。
在性能方面，Oracle 协议的主要缺点是它需要更多的线路以外的往返：它被设计为在本地网络上工作，具有低延迟。通过 Internet 连接，它会慢得多，并且出于安全原因，很可能会被封装到 VPN 中——进一步降低性能。
我们不应该以抽象的方式谈论“性能”。有几种方法可以给猫剥皮……如果您想要原始查询性能，请使用另一种数据库，例如 Redis。
但是对于业务应用程序来说，主要的“性能”点可能更多是关于扩展。在这里，Oracle 协议的数据库连接成本更高。维护连接，尤其是维护事务，可能非常苛刻。在典型的 Oracle 服务器上，您最多可以同时维护几十个/百分之一的数据库连接。而让一个 REST 服务器同时维护数千个客户端非常容易。即使您目前只期望少数客户，您如何想象您的未来？如今，所有严肃的应用程序都期望有一个类似 REST 的接口。并将数据库连接保持在服务器端本地。
如果我们让所有功能和查询都在客户端（即使我们会做 Web 客户端），这不是安全问题吗？
安全性是另一个问题，这里的 REST Web 客户端具有已知且经过验证的策略，并具有适当的审计方法。在 REST 接口中，您永远不会“让所有功能在客户端上”。该框架提供了多种身份验证和授权方式 -检查文档，从 URI 签名到 JWT。
就安全性和可扩展性而言，向整个 Internet 开放 Oracle 端点并不是一个好主意。甚至甲骨文也在为适当的网络提供专门的解决方案。
无论如何，像mORMot这样的框架被设计为在一个包中提供 REST、SOA、ORM 和 Web MVC，并且性能是从头开始驱动的——作为奖励。如果您希望设计 RAD VCL/FMX 应用程序，请使用直接数据库连接，并以数据为中心。如果您想要更开放和可维护的东西，请考虑 SOA，并以服务为中心。今天，我将我所有的 SOA 解决方案开发为微服务，使用独立的数据库，mORMot作为工具，具有巨大的性能 -每秒高达数百万个数据项。
对我来说听起来像是一个模糊的故事，除非我有充分的证据证明，否则我很难相信这一点。即便如此，在比较这种不同架构方式的性能时，也很容易比较苹果和橘子。
我不认为 https 通常比直接连接更快，但这取决于很多变量。
此外，mORMot 本身也需要连接到数据库，为此它可以使用一些直接 Oracle 访问（我假设与您比较的相同），或通常相同或更慢的 OleDB（又名 ADO）比 DOA，所以那里没有收益。mORMot 只有额外的开销。请参阅mORMot 的软件架构。
那么，怎样才能更好呢？
例如，如果中间层在客户端不能使用连接池时使用连接池。在这种情况下，拥有一个用于池连接的中间层可以带来更好的性能，因为不需要在每个请求上建立新的连接。这可以节省大量开销。
缓存也是如此。如果您想构建一个网站或 Web 应用程序，如果可以缓存查询结果而不考虑用户，那么拥有一个中间层可以大大改善缓存。如果你有客户端缓存，你只为那个用户/浏览器/会话缓存它，而在中间层，你可以为所有访问者缓存一些数据，这是一个很大的好处。
如果在涉及数据库之前需要进行大量处理。这在高端中间层上可能更快。再说一次，如果你有很多用户，你可能会用完硬件容量（或云预算），你可能会考虑在客户端上做部分工作。
所以三层有各种各样的好处。whosrdaddy 已经将其命名为可扩展性、可移植性和冗余。性能也可以是好处之一，如果你勾选上面列出的任何一点，但一般来说，这不是从 2 层到 N 层的主要原因。