表达式引擎：何时使用渠道以及何时不使用渠道？

Question

作为开发人员和用户，我仍然是Expression Engine的新手。我面临的问题是，我的许多知识都是通过使用渠道系统找到方法来完成开发人员传统承担的任务（例如产品库）的用户传递给我的。

我想知道的是人们的观点是什么时候最好建议客户使用这个，什么时候不使用。

让我用一个例子，一个客户想要一个有事件发生地点的系统。之前的开发者已经选择使用会场系统和事件通道系统，并编写一些自定义代码来试图将两者结合在一起，具体而言，因为没有足够的钩子来完成某些后台自动化任务，如查找创建或更新场馆地址的长/宽。

我正在接受别人的工作很大程度上，但它不是他们的错，这是他们给的信息，因为他们也是新系统。

在任何其他项目中，这将是一个主细节类型设置，事件属于场地，我可能通过模块在管理区域编写2个自定义表格，编辑器，然后在页面中使用常规自定义代码来显示并对信息采取行动 - 通过这种方式，我可以控制用户点击提交时发生的情况。

但是，煽动方是Expression Engine的资深用户，并以“哦，把它放在频道中，然后有这个标签和那个标签等等”的方式指示以前的开发者。

所以，我是否错过了这一点，或者我是对的，这不适合渠道系统，什么时候应该使用渠道，什么时候不使用渠道？

感谢朋友。

Answer 1

这个问题是非常假设的，每个开发人员都会给你一个不同的答案，因为这一切都取决于需求以及EE开发人员的工作方式。

基本表达式引擎允许您以多种方式构建构建，但没有一个是对与错，虽然有些更容易，有些更难，其他则更加简单。

基本上渠道是数据“条目”的组 - 这些可以是任何东西。使用您的示例，场地可以是一个与主题相关的字段（例如位置，大小，价格等）的渠道。另一个频道用于包含不同字段的事件（例如日期，类型，位置）。

大多数情况下，任何东西都可以插入到一个通道中。但是会员详细信息最好在本地会员功能中进行（尽管有一个商业附加功能可以保存频道中的会员数据）。

您引用了以前的开发人员方法 - 这可能是因为他们使用了需要将数据分开保存到渠道的第三方附件，或者对最佳方法缺乏了解。或者只是因为开发者决定以这种方式来对待它！我怀疑最后的开发者会把一个会员（场地）与一个入场（活动）联系起来，将活动与场地联系起来。基本EE功能允许相关条目允许您将1个条目与另一个条目（例如Event - > Venue）相关联，或者使用优秀的Playa附加组件，因此这种方法实际上并不是必需的。

就我个人而言，我总是将数据存储在渠道以及本地会员功能（例如管理员，网站访问者，客户等）中的人员/成员。我只会建立一个附加组件（利用它自己的表格/数据）来存储额外的信息，如果它超出了EE可以存储的范围。

Answer 2

为了回答您的实际问题（它诚实地扩展了what Stack Overflow questions are supposed be的范围）：您应该为场地和活动频道使用频道，并且活动条目中的场地字段是与场地相关联的“相关条目”字段类型渠道。这是“标准”EE方式，与传统数据库模式最为相似。