c# - 数据库中介是好的系统设计吗？

Question

背景:我们有许多服务器进程和客户端应用程序完全在内部使用，在一个相当受控的环境中。我们每天都会捕获大量数据，这些数据会进入几台数据库机器。大部分内容都是 C#，还有一些 C++ 应用程序。

几乎每个应用程序都对数据库数据有一些基本的(如果不是广泛的)依赖性，无论是历史数据、每日计算值还是各种参数。随着整个环境变得更加庞大，我一直想知道在所有客户端和服务器应用程序与数据库之间插入一个中介(一种“数据库数据代理”)的意义。任何需要来自数据库的值的应用程序都会向数据代理发出请求，而不是调用存储过程的 dll 包装函数。

一个直接的缺点是数据会在网络中进行两次旅行:从数据库到代理，以及从代理到调用应用程序。看起来形式不佳，但每个请求中的数据量足够小，就性能而言我可以接受。

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

我是否过度设计了它，或者它可能是一个有值(value)的架构？

编辑:感谢迄今为止所有的精彩评论，值得深思。

Answer 1

这取决于您要用它完成什么。根据Rocky Lhotka ，你应该只在被迫，一路踢打和尖叫的情况下添加一个等级。

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

看起来主要原因是可维护性。它是否超过了您不拥有等级所获得的好处？