C# 数据库中介是一个好的系统设计吗？

背景：我们有许多服务器进程和客户端应用程序，它们完全在内部使用，在一个相当受控的环境中。我们每天都会捕获大量数据，这些数据会进入两台数据库机器。大部分都是C语言，有几个C++应用程序。 无论是历史数据、每日计算值还是各种参数，几乎每个应用程序都对数据库数据有一些基本的（如果不是广泛的话）依赖性。随着整个环境变得越来越杂乱无章，我一直在想，在所有客户端和服务器应用程序与数据库之间插入一个中介（一种“数据库数据代理”）有什么意义。任何需要db值的应用程序都会向数据代理发出请求，而不是调用存储过程的dll包装函数

一个直接的缺点是，数据将在网络上进行两次传输：从db到代理，从代理到调用应用。看起来形式很差，但每个请求中的数据量足够小，所以就性能而言，我可以接受

一个（看起来）好处是，设置一个测试环境很简单，因为它只需要设置一个测试数据代理，并且不需要在其他任何地方本地维护db连接字符串。此外，我一直在考虑创建一种迷你请求语言，这样您就不必为可能请求的每个数据集枚举函数（不是GetX（）和GetY（），而是Get（“name=X”）

是我设计得太过了，还是它可能是一个有价值的建筑

---

编辑：感谢到目前为止所有的精彩评论，非常值得思考。

只有你才能回答这些问题：

• 这样做的好处是什么
• 这样做有什么问题/风险
• 您是否需要这样做来简化测试，甚至使测试成为可能
• 如果你做了这个改变，当它上线并崩溃时，你会被解雇吗
• 如果你做了这些改变并且上线，你会得到提升吗
• 等等

---

数据代理听起来是为应用程序提取多个数据源的一种非常好的方法。整合、更改存储库或在将来需要时以其他方式移动数据都很容易。

这取决于您试图用它来完成什么。根据，只有在被迫的情况下，才应该添加一层一路尖叫

我同意他的观点：除非需要，否则不要分层。我认为有充分的理由添加额外的分层，通常是出于安全性、可伸缩性和可维护性的目的。问题变成了：你的理由有效吗

---

看起来主要原因是可维护性。这是不是超过了你得到的好处，因为没有层次？

我可能误解了一些东西，但是在我看来你应该考虑一些实体框架。这是一个你可以用来“映射”的框架。您与db的交互会影响某些域对象。通过这种方式，您可以在本地处理从db中填充的域对象，并且当需要将对象的状态持久化到基础时，框架会处理所有来回的连接。通过这种方式，您还可以轻松地模拟这些域对象进行单元测试，而无需g数据库连接

---

查看一个好的实体框架替代方案。

如果您已经拥有与数据库相关的专有技术，我认为这是一个不错的决定

我能想到的好事情：

• 如果数据模型一致，您可以轻松插入新工具，而无需对其他应用程序进行任何更改
• 也许你可以比你的应用程序更可靠地运行数据库，所以如果其中一个失败，另一个仍然可以工作
• 您可以使用数据库工具进行备份和回滚
• 您可以使用sql或一些可视化工具直接操作数据来执行紧急修复

---

但是，如果您必须在此过程中学习新的框架，那么这些好处可能不值得您付出额外的初始努力。

作为一个系统的前架构师，该系统也大量使用数据库作为“中心”，我可以说，您应该注意以下几个缺点。我们的系统使用数据库：

• 作为事务存储（典型的OLTP内容）
• 作为临时队列（已提交但未处理的事务）
• 作为历史数据存储（已处理事务的结果）
• 作为互操作层（从其他系统发出的未翻译命令或事务）

其中一个主要缺点是所有权成本。当您的数据库成为这么多类型操作的单点故障时，就有必要确保它们都托管在高可用性环境中。这不仅从硬件角度看很昂贵，而且支持部署到HA环境也很昂贵s、 因为开发人员通常对内部的可见性非常有限

第二个缺点是，您必须认真地对所有表进行完整性设计。在典型的SOA环境中，您对数据如何修改有完全的控制。当您通过数据库表公开它时，必须考虑到任何具有正确凭据的应用程序都有修改数据的能力。必须仔细考虑约束的实用化实现。如果您有一个服务管理持久性，那么在数据库上的约束中可能会宽松得多，并在代码中强制执行。 第三，如果您想要公开数据库表当前允许您向外部提供的任何功能，那么您必须编写服务代码，这样您就可以从策略上更好地执行服务代码，而不是响应请求

第四，直接与数据层的UI交互会产生安全风险，特别是当客户端是厚客户端时

最后，编写响应事件（服务调用）的代码