Elixir/Phoenix 控制器助手的惯用函数名称答案

【问题标题】：Idiomatic function names for Elixir/Phoenix controller helpersElixir/Phoenix 控制器助手的惯用函数名称
【发布时间】：2018-11-11 17:47:55
【问题描述】：

我正在我的 Phoenix 网络应用程序中编写一些 get 助手。在 Rails 中，您通常会命名（或缺少方法）助手，如 find_account_by_email(email) 等。

模式匹配对 Elixir/Erlang 来说似乎如此核心，我想知道我是否更适合编写我的助手，例如：

def get_account({email: email}) do
  # ...
end

Phoenix 将 get_account(id) 方法存根，所以我觉得重用名称和模式匹配更习惯？

【问题讨论】：

标签： elixir phoenix-framework

【解决方案1】：

欢迎来到 Stack Overflow！

虽然phoenix-framework 可能被称为“Elixir 的 Rails”，但设计模式和架构考虑因素却大不相同。公开“可能用于很多事情”的随机函数并不是哲学的一部分。

但好的部分是，如果您的用例确实需要这样的东西，使用宏、行为或协议扩展现有功能非常容易。 对于您的简单用例，您确实可以创建一个通用方法（或一组方法），但我会失去tuple：

defmodule Account do
  def get(clauses) do
    Repo.get_by(Account, clauses)
  end
end

您可以使用以下方式调用它：

Account.get(email: "user@example.com")

但我会争辩说，如果用另一种方式替换一条线路，是否确实为您的代码库增加了足够的价值来保证它。

^{旁注：我 actually created a library 将 Rails 样式的模型助手添加到 Elixir 应用程序中的 Ecto 模式中，以方便 Rails 开发人员使用 Phoenix，公开类似于什么的方法活动记录可以。另请参阅note about complex queries。}

【讨论】：

“但我会争辩说，它是否真的通过将一个衬里替换为另一个衬里为您的代码库增加了足够的价值。”，这是否暗示我应该在我的其他代码中直接使用 Repo ?它实际上是从后台 genserver 调用的，并且在任何地方都包含 Repo，这似乎打破了 phoenix 的“上下文”所布置的封装。
我同意一次又一次地重复Repo 调用会很累并且容易出现错误，因此理想情况下，您应该有一个封装重要和重复查询的模块。但是对于一次性调用，将逻辑封装在另一种方法中是没有意义的。您应该只使用现有的库方法。
另外，YourApp.Repo 通过抽象出应用程序与数据库或其他模式的交互方式，实际上在 Phoenix 应用程序中表现得像一个单独的上下文。除非您的查询变得非常复杂，否则您不应该在另一个上下文中进一步抽象它们。