设计数据库访问层答案

【问题标题】：Designing the database access layer设计数据库访问层
【发布时间】：2016-05-05 20:43:16
【问题描述】：

在设计系统架构方面，我认为自己非常业余，而我目前正处于这样做的过程中。

特别是，我正在尝试提出一种有效且可维护的方法来重新实现所有具有查询数据库以读取数据的方法/函数的类，然后将其发送到上游以供另一层处理，最后接收将处理后的数据写回数据库。

当然，这个普遍的问题已经解决了。我打算遵循 DDD 方法，以便访问数据库的方法是“基础架构”层的一部分。是否有设计系统（或类结构）来实现这一目标的最佳方法？我应该只有一个网关来从所有类都应该引用的数据库中读取/写入，还是每个组件都应该有自己的与数据库通信的方式？有没有标准的方法来做到这一点？

我注意到这个问题可能有点宽泛，但对于那里的专家来说，你肯定已经经历过这个并且能够提供帮助。

【问题讨论】：

我认为在谈论架构解决方案时，这里没有标准......这完全取决于最近应该更改应用程序的哪些部分，从事项目的团队的独立程度等等。

标签： c# oop architecture database-connection

【解决方案1】：

有以下几点需要考虑：

DAO 模式 - 利用 DAO 对象（针对每个域对象）创建 DAO 层，上层（例如服务层）可以使用它。
架构 - 如果您正在考虑微服务架构，那么 UI、服务、数据库访问 (DAO) 和数据库 - 所有这些都将是单个可部署单元。因此，设计模式将与所选的架构方法保持一致。
API 网关 - API 网关（与架构方法一致）。在设计 API 时考虑功能用例，而不仅仅是提供 CRUD 操作或技术特定的 API。

【讨论】：

【解决方案2】：

作为一种公认的做法，您的表示层、业务逻辑和数据访问（有些人称之为后端层）应该是完全分开的。 Microst 的 MVC 概念只是为实现这一目标而努力的一个明智的例子。来自 Google 的 AngularJs 是 MVVM 的另一个示例，它在客户端而不是 Asp.net MVC 服务器端编写干净的代码。因此，这里清楚地确定了最佳实践应该是什么。至于你的问题，我想说设计符合高度优化设计范式的东西并不需要某种方式，而是需要了解多种方式和智慧来选择单一或多种方式，甚至混合它们以满足您的需求的经验。至于您关于数据访问网关的问题，让我这样说，维护多个连接是一项非常消耗资源的工作，因此理想情况下，维护单个连接的单个静态实例数据类是一种适当的方法，并且所有数据都提供服务, 操作方法应该放在那里。在 Web 开发中，我们熟悉通过操作/消息契约公开对象的 Web 服务。分离和封装是这里的关键。但是请确保没有什么是完美的，尽管 Asp.net MVC 拥有分离所有这些层的最佳方法，但他们有 Razor 来反驳它。但这是必要的。地狱与紧密耦合的后端和前端或意大利面条代码的偏执。当它适合您的需求时，这一切都是有意义的。这里的关键只有经验可以教给我们做某事的优化方式或方法。这就是我回答的返回值！

【讨论】：