设计数据库访问层

Question

在设计系统架构方面，我认为自己很业余，而且我现在发现自己正在做这件事。

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

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

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

Answer 1

有以下几项需要考虑：

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

Answer 2

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