tier应用程序中的哪个层应该创建历史记录？

Question

我有一个3层web应用程序，它有一个web视图层、一个业务逻辑层和一个数据库持久层。我正在添加一个功能，它使用记录填充历史表，当且仅当要保存的元素发生了更改(它比较了以前的记录和当前的记录，如果有任何变化，则保存历史记录)。

我不确定构建历史记录并保存它们的逻辑属于业务逻辑层还是数据库持久层。数据库持久层只有一个saveElement方法。业务逻辑层有多个地方调用数据库持久性的saveElement方法。

在数据库持久层中放置历史逻辑的

优势：

-If逻辑被放置在业务逻辑层，存在这样的风险:一些业务逻辑层调用者可能忘记调用方法来创建历史记录。如果逻辑被放置在数据库持久层中，则保证任何保存的记录都会被创建历史记录。

-The站点为数据库层中的其他信息提供了另一个历史系统，如果这两个系统位于相同的位置，则会产生一致性。

将历史逻辑放置在业务逻辑层中的

优势：

-There在构建历史记录方面有点复杂，数据库层主要用于调用/运行sql查询。

那么，是否有任何令人信服的理由将此逻辑放置在业务逻辑层或数据库层？还是说逻辑放置在哪里并不重要？

Answer 1

那得看情况。

具体来说，它取决于您希望记住更改的逻辑级别。如果"element“是一个合理的历史记录，并且您已经在持久化层中有了saveElement，那么扩展saveElement来记录对历史/存档记录的更改也是有意义的。

然而，如果您试图将业务级别的事件(如“购买项目4017库存”)存档在比您正在存储的元素更高的级别上，则需要在业务层中这样做，因为这是理解活动意图的地方。

这是一个典型的分层问题：“意向信息在哪里？”通常是直截了当的回答(例如：“我们想保存历史信息，而且我们已经有了一个持久层，所以这就是它应该去的地方！”)如果不是不正确的话，更高的层分解他们的活动，并将持久化层称为更多的“保存这个！”马力马。更高级别的概念通常在过滤到持久性层时不可用。那么，您至少需要调整层间的API，以便业务层能够像它所调用的saveElement那样声明它的意图(例如“项目X")。