我试图了解Phoenix 1.3上下文。
我了解上下文之间的可分离性（在我看来，我认为这是具有明确定义的API边界的微型应用程序），但是在试图弄清楚如何在它们之间建立多对多关系时，我很费力。 / p>
在构建松弛克隆的情况下，一个用户可以有很多聊天室，而一个聊天室可以有很多用户。
采用基于“模型”的方式，您将创建一个中间表user_rooms（具有user_id，room_id字段），然后执行join_through。
让我感到困惑的是：
（作为背景，我正在尝试执行此https://medium.com/@benhansen/lets-build-a-slack-clone-with-elixir-phoenix-and-react-part-4-creating-chat-rooms-80dc74f4f704的第4步）
答案 0 :(得分：1)
思考上下文的一种方法是在设计应用程序时将它们视为抽象层。放在the docs中，
Phoenix项目的结构类似于Elixir和任何其他Elixir 项目–我们将代码分成上下文。上下文将分组 相关功能（例如帖子和评论）通常封装在一起 数据访问和数据验证等模式。通过使用上下文， 我们将系统解耦并隔离成可管理，独立的系统 零件。
因此，具有其自身基础架构的模型本身就是您分组为上下文的单元。模型可以具有更细粒度的api，这对于内部工作是必需的。上下文反过来仅公开对其他应用程序组件或上下文有用的方法，从而隐藏了模型的底层实现细节。
为了绝对隔离，没有必要将上下文边界向下扩展到整个模型级别。相反，您可以像往常一样创建模式，并具有模型上所需的所有多对多关系。然后直接在模型上实现任何低层方法。仅将那些属于上下文的公共api或涉及多个模型的私有方法的方法放在上下文中。
更新
在您的情况下，您可能会遇到您放置Chats方法的rooms上下文。它的签名可能是Chats.rooms_of(user)。 Repo.get()也会进入上下文，例如def get(id), do: Repo.get(User, id)。这些模型最终包含变更集，验证方法，私有方法，而这些模型不依赖于其他模型。反过来，上下文将获得该组大多数可公开使用的业务逻辑方法。