问3层(物理)架构是否效率低下？

EN

这取决于您的应用程序的使用和您对安全性的要求。如果您的应用程序正通过Internet使用，并且您正在以任何方式存储任何可能敏感的内容，强烈建议您为数据库添加物理删除。永远不要让任何人从外部进入任何可以直接访问你的数据库的机器。人们可以，也将会试图破坏你的安全，原因就是他们没有更好的事情做。

可伸缩性也可能是一个因素，无论是在表示层前面(在web服务器前面)还是在数据库中。在表示层前面放置负载均衡器允许将传入请求路由到可以独立管理的机器阵列。在需要时，可以将机器添加到池中，也可以将其移除以进行维护。在其他层之间放置负载均衡器可能会产生相同的影响。我们的想法是提供一个灵活的、动态的后端环境，可以根据需要进行调整。

每当你发现自己在问“X是不是低效的？”你应该立即问自己三个前兆问题：

1. 被称为“低效”，您认为哪些资源应该得到有效利用，哪些资源可能得不到有效利用？时间？太空？带宽？开发时间？
2. ，你为什么要关心？不，说真的，如果你要花一分钟来回答这个问题，那肯定是有原因的。这个reason?
3. Compared是什么？

就您对可伸缩性的评论而言:有一段时间，我不幸地负责维护一个系统，该系统的架构师被告知，最大限度地减少到数据库的往返将使应用程序具有可伸缩性。他利用了这种洞察力，并将其付诸实践。您可以阅读有关此项目的here。我突然想到，我应该提到，在该应用程序的整个十多年的生命周期中，没有超过四个用户同时登录。

低效是旁观者的眼睛。

例如，在客户端上执行所有操作可能会增加客户端计算机的内存占用或CPU/网络要求。如果可以将此工作卸载到服务器/服务器场，则可以省去仅为运行软件而对客户端PC进行硬件升级的麻烦。如果需要更多资源或升级，可以在业务逻辑层添加/完成，而不会影响客户端。

此外，当您需要在基于web的系统、Outlook外接程序或iPhone应用程序中公开应用程序的某些功能时，将业务逻辑放在自己的层上可能会更有效率(从软件开发的角度来看)。您不希望在业务逻辑稍有变化时就必须更新所有这些系统。

安全性可能会更好，因为您的用户不需要直接访问数据库服务器，他们由应用程序服务器隔离。

它还迫使您以模块化的方式考虑您的应用程序，使用定义良好的接口，这可能对您的应用程序的设计具有架构上的好处。