我很好奇您将如何处理以下数据库访问。
我们建议您有一台计算机，它托管您的数据库作为其服务器工作的一部分，以及多台客户端 PC，上面有一些需要从该数据库获取信息的客户端软件
AFAIK 有两种方法可以做到这一点
所以我想知道的是： 每种解决方案的优缺点是什么？ 还有其他解决方案可能“更好”地完成这项工作
【问题讨论】：
标签： database design-patterns client-server data-access-layer
我绝对会选择第 2 条建议。没有代理，任何客户端应用程序都不应与数据存储区通信，即：
ClientApp -> WebApi -> DatabaseBroker.class -> MySQL
当您分离关注点并为数据存储定义有组织的吞吐量时，这是执行此操作的正确方法。
一些好处是：
将客户端与数据库解耦
您可以将所有客户端的所有升级、添加和可操作性集中在一个位置 (DatabaseBroker.class)
它非常可扩展
在业务逻辑方面是安全的
用这个外行的例子来这样想：
不允许海军陆战队携带自己的武器上战场（客户端应用程序直接与 DB 对话）。相反，他们从军械库 (API) 中检查武器。军械库可以控制所有武器、维修和升级（数据库中的数据），并决定谁得到什么。
【讨论】：
你所描述的听起来像是两种不同的multitier architectures。 第一点与两层匹配，第二点可能是三层。
AFAIK 有两种方法可以做到这一点
您可以将您的应用程序划分为多个物理层，因此，您会发现比上述更多的情况适合这种架构（n 层）。
每种解决方案的优缺点是什么？
通常，将应用程序分层的动机是为了实现某种非功能性要求（可维护性、可用性、安全性等），问题是当您添加额外的层时，您也会增加复杂性，例如：您的应用程序组件需要相互通信，当它们分布在多台机器上时，这会更加困难。
还有其他解决方案可能“更好”地完成这项工作。
我不确定您在这里所说的“工作”是什么意思，但请注意，您不需要添加额外的层来访问数据库。如果您在几台机器上安装了桌面应用程序，那么经典的客户端/服务器（两层）模型就足够了。但是，基于 Web 的应用程序需要一个额外的层来与浏览器交互。在这种情况下，数据库访问不是添加这个额外层的动机。
【讨论】：