3

我有一些“遗留”的 Scala 代码（类似 Java），它进行一些数据访问。有一个装饰器可以跟踪 DAO 方法（收集指标）的使用情况，如下所示：

class TrackingDao(tracker: Tracker) extends Dao {
    def fetchById(id: UUID, source: String): Option[String] = {
        tracker.track("fetchById", source) {
            actualFetchLogic(...)
        }
    }
    ...
}

我正在尝试将其建模为 Free monad。我为 DAO 操作定义了以下代数：

sealed trait DBOp[A]
case class FetchById(id: UUID) extends DBOp[Option[String]]
...

我看到两个选项：

a）我可以制作两个解释器DBOp，一个执行实际的数据访问，另一个执行跟踪，并将它们组合在一起，或者
b）我使 Tracking 成为一个显式代数，并使用 Coproduct 在同一个for组合中使用它们或者
c) 完全不同的东西！

第一个选项看起来更像是一种“装饰器”方法，它与 绑定DBOp，第二个是更通用的解决方案，但需要显式调用“跟踪”代数。

另外，请注意source原始fetchById调用中的参数：它仅用于跟踪。我宁愿从 API 中删除它。

这是实际的问题：我如何为跟踪建模？

4

2 回答 2

5

您的问题并不完全清楚，但是如果跟踪是一种环境效应，当您执行数据库访问时应该“发生”并且source只是用于跟踪目的的参数，那么您可能根本不必在您的免费语言中提及它。您可以使用您现在拥有的 ADT 并解释(Tracker, Source, OtherStuff) => IO[A]为例如，因此您得到的是一个函数，一旦您给它一个Tracker和源以及您需要的任何其他内容（例如 DB 连接），它将生成一个程序来进行 DB 访问，并且跟踪实现对解释器来说是完全私有的。这使您可以编写数据库程序，而无需考虑跟踪。

另一方面，如果您确实需要讨论业务逻辑中的跟踪，那么我们可能需要更多关于拥有多个Trackers 和sources 的含义以及如何引入和使用它们的信息。可能需要副产品或扩展语言或嵌套语言来处理您需要表达的内容。

于 2017-03-13T08:02:26.503 回答
2

与我们行业中的所有事物一样，直接的答案是“视情况而定”:)。由于“跟踪”在这里是一个模糊的概念（我不知道该领域的细节），我会说你有两种可能的情况（或者至少我看到了两种）

a) “跟踪”是您的业务词汇的一个元素

如果跟踪是您的业务使用的词汇表中的一个单独关注点，那么我将使用代表该关注点的单独代数。与此类似的东西是“身份验证和授权” - 即使它是“低级”问题，它仍然是业务语言的一部分（“作为管理员，我想......”）我会用单独的代数去这里

b）“跟踪”是一些“调试”、“记录”的机制

如果跟踪不是语言的一部分，而是您为维护而保留的机器元素，那么我会将其保留在它所属的地方 - 机器。我会选择一个解释器，它会对“跟踪”（记录、调试）这些不同的调用产生副作用。

换句话说，如果现在你没有一个测试来测试“如果我做这件事，那么这应该被跟踪”，那么我肯定会在这里选择选项 b)

于 2017-03-13T08:25:42.537 回答