背景：我们有一些服务器进程和客户端应用程序完全在内部使用，处于相当受控的环境中。我们每天都会捕获大量数据，这些数据会分配到几台数据库中。大多数都是c＃，有一些c ++应用程序。
几乎每个应用程序都有一些基本的（如果不是广泛的）依赖于数据库数据，无论是历史数据，每日计算值还是各种参数。随着整个环境变得越来越庞大，我一直想知道在所有客户端和服务器应用程序以及数据库（一种“数据库数据代理”）之间插入中介的意义。任何需要来自db的值的应用程序都会向数据代理发出请求，而不是调用存储过程的dll包装函数。
一个直接的缺点是数据将通过网络进行两次访问：从数据库到代理，从代理到调用应用程序。看起来很糟糕，但是在每个请求中数据量都足够小，只要性能好，我就可以使用它。
一个（看似）好处是建立一个测试环境是微不足道的，因为它只需要设置一个测试数据代理，并且不会在其他地方本地维护数据库连接字符串。另外，我一直在考虑创建一个迷你请求语言，所以你不必枚举你可能要求的每个数据集的函数（而不是GetX（）和GetY（），会有Get（“name = X”）< / p>我是否过度设计了这个，或者它可能是一个有价值的架构？
编辑：感谢迄今为止的所有好评，非常值得深思。
答案 0 :(得分：5)
这取决于你想用它完成的任务。根据{{3}}，如果你被迫，一直踢，尖叫，你应该只添加一个等级。
我同意他的观点：除非你需要，否则不要分层。我认为有正当理由添加额外的层，通常是为了安全性，可伸缩性和可维护性。问题变成：你的理由是正确的吗？
看起来主要原因是可维护性。它是否超过不拥有等级所带来的好处？
答案 1 :(得分：2)
只有你能回答这些问题：
答案 2 :(得分：1)
作为一个系统的前架构师，它也大量使用数据库作为“集线器”，我可以说你应该注意几个缺点。我们的系统使用数据库：
其中一个主要缺点是拥有成本。当您的数据库成为这么多类型操作的单点故障时，有必要确保它们都在高可用性环境中托管。从硬件角度来看，这不仅昂贵，而且支持部署到HA环境也很昂贵，因为开发人员通常对内部的可见性非常有限。
第二个缺点是你必须认真设计所有表的完整性。在典型的SOA环境中，您可以完全控制数据的修改方式。通过数据库表公开它时，必须考虑具有正确凭据的任何应用程序都能够修改数据。因此，您必须仔细考虑约束的实用实现。如果您有一个管理持久性的服务，那么您可能会对数据库的约束更加松散并在代码中强制执行它们。
第三，如果您想要公开数据库表当前允许您向外部各方提供的任何功能，您必须始终编写服务代码，这样您可以更好地服务于战略性而不是对请求作出反应。 / p>
第四，直接与数据层进行UI交互会产生安全风险，尤其是在客户端是胖客户端时。
最后，编写响应事件（服务调用）的代码比轮询代码容易得多。通常，每当新项目需要新的“监控服务”时，严重依赖数据库轮询的组织最终会重新发明轮子。可以通过创建“框架”来避免这种情况，但这些问题有其自身的缺陷（主要是处方与采用）。
这只是我遇到的问题的清单。它并不一定意味着阻止您使用数据库来实现这些功能，但它有助于提前了解危险，因此如果它们成为问题，您至少可以为它们做好计划。
修改
想到另一个让我们痛苦的场景。对更改进行版本控制可能很困难。例如，如果需要更改表的形状（normalize / denormalize），如果多个应用程序依赖它，则会产生级联效果。在SOA场景中，它更容易，因为您可以保留旧API，更改内部交互以使其与更改的表一起使用，并允许消费者按照自己的计划迁移到新版本。
答案 3 :(得分：0)
数据代理听起来像是一种抽象出应用程序的多个数据源的好方法。如果将来需要，可以很容易地合并，更改存储库或以其他方式移动数据。
答案 4 :(得分：0)
我可能会误解某些东西，但在我看来，你应该考虑一些实体框架。这是一个框架，您可以使用该框架将与db的交互“映射”到某些域对象。这样你就可以在你的数据库中填充的域对象本地工作，当需要将对象的状态持久保存到基础时，框架会来回处理所有连接。通过这种方式，您还可以轻松地模拟这些域对象以进行单元测试，而无需数据库连接。
查看NHibernate以获取良好的实体框架替代方案。
答案 5 :(得分：0)
如果您已经拥有与数据库相关的专业知识，我认为这不是一个糟糕的决定。
我能想到的好事：
但是如果你必须在这个过程中学习新的框架，那么这些好处可能不值得额外的初步努力。
答案 6 :(得分：0)
“任何需要来自db的值的应用程序向数据代理发出请求”
当数据库技术在40多年前发明时，那些发明创造的人就有了“任何需要来自db的值的应用程序向dbms请求”的想法。
您是否考虑过您已经拥有“数据经纪人”的可能性，并且创建自己的第二个可能没有什么附加价值？