是一个数据库中介良好的系统设计?

2 c# database

背景:我们有一些服务器进程和客户端应用程序完全在内部使用,处于相当受控的环境中.我们每天捕获大量数据,这些数据都存储在几台数据库中.大多数都是c#,有一些c ++应用程序.

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

一个直接的缺点是数据将通过网络进行两次访问:从数据库到代理,从代理到调用应用程序.看起来很糟糕,但是在每个请求中数据量都足够小,就性能而言,我对它很满意.

一个(看似)好处是设置一个测试环境是微不足道的,因为它只需要设置一个测试数据代理,并且不会在其他地方本地维护数据库连接字符串.另外,我一直在考虑创建一个迷你请求语言,所以你不必枚举你可能要求的每个数据集的函数(而不是GetX()和GetY(),会有Get("name = X")

我是在过度设计这个,还是可能是一个有价值的架构?

编辑:感谢所有伟大的评论到目前为止,伟大的思考.

Ran*_*pho 5

这取决于你想用它完成的任务.根据Rocky Lhotka的说法,如果你被迫,一直踢,尖叫,你应该只添加一个等级.

我同意他的观点:除非你需要,否则不要分层.我认为有正当理由添加额外的层,通常是为了安全性,可伸缩性和可维护性.问题变成:你的理由是正确的吗?

看起来主要原因是可维护性.是否超过了没有等级所带来的好处?