设计：负载期间数据操作的业务逻辑或数据存储

Question

我已经在数据存储和业务逻辑之间分离了我的程序。

在我的数据库中，我有两个非常相似的表，一个存储已提交的更新（每个实体有多个条目），一个条目是我正在处理的临时数据。

这意味着当我加载数据时，“正确”数据是临时数据或提交数据的最新值。

我的问题是决定提供此信息是“数据存储”还是“业务逻辑”问题。

做恶魔倡导者我最终得到了2个声明。

---

数据存储问题

由数据结构决定是否能够提供检索简单定义的数据请求的答案，如何完成数据存储。即使这是通过混合代码和数据加载完成的，那么这很好，只要请求得到修复并有明确的答案。

因此，如何将这与临时信息一起存储不应该是业务逻辑的关注点，这意味着如果我稍后重构或重做数据结构，则业务逻辑的请求不会改变。所以解决方案是从两个表单加载最新值并比较它们，并以定义的格式返回最新的

---

业务逻辑问题

确定哪些数据是最新的以及它的处理方式不是数据问题，因此操作数据的代码应该放在业务逻辑中，可以通过包装器（在业务逻辑中）来避免在以下情况下重构大量代码数据存储的变化。因此，应在业务逻辑方面请求和比较两个结果，使数据存储仅维护数据检索。

---

我倾向于将这个逻辑放在数据存储中，因为业务逻辑正在询问一个简单的信息并发送一个请求，由于其他问题，这个问题决定以特定方式存储，以后可能不会更改影响业务逻辑部分。所以你的想法是什么。

您将在何处放置信息，为什么要使用/避免使用业务逻辑/数据存储来完成此任务？

Answer 1

我会使用商业逻辑层。 （以上您的描述）

您遇到此问题/难题的原因是您不使用域层。

业务层应使用此域定义与数据层进行通信。 如果数据层已拆分为2个表。然后它应该结合检索。

因此，如果没有域或模型，那么数据和业务层之间的“合同”是什么。 在哪里定义。

回答域/模型问题或定义合同/接口的位置。 然后你会更接近你的答案。

推荐阅读。的 DDD 域驱动设计或有时称为域驱动开发

Answer 2

决定使用两个表来保存永久和工作数据是一个数据存储，还有其他方法来实现这个概念。理想情况下，您应该能够更改数据操作基板，而无需更改业务逻辑。

因此，数据存储层应负责协调实现并提供数据的连贯视图。实现这一目标的最佳方式是使用抽象，例如视图或API。选择最适合您的架构的方法。