继续将我的CakePHP 1.3应用程序端口工作到3.0，并遇到另一个问题。我有许多功能因某些设置而异的区域，我之前使用过模块化组件方法。例如，联赛可以进行循环赛，阶梯赛或锦标赛赛程。这会对调度算法本身产生影响，因此配置每种类型需要不同的设置，但也决定了渲染的方式，关系破坏等等。（这只是我有类似内容的10个区域之一，尽管并非所有这些都受到以下问题的影响。）
我过去的解决方案是使用基本实现创建一个LeagueComponent，然后将该类扩展为LeagueRoundRobinComponent，LeagueLadderComponent和LeagueTournamentComponent。当控制器需要执行任何特定于算法的操作时，它们会检查联盟表中的schedule_type字段，创建适当的组件，并在其中调用函数。这仍然很好。
我提到这也影响了观点。对此的旧解决方案是通过$this->set将联盟组件对象从控制器传递到视图。然后，视图可以查询它的各种功能。这无疑是有点愚蠢的，但显而易见的替代方案似乎是提取视图可能需要的所有信息并单独设置它们，这对我来说似乎没那么好。如果有更好的选择，我会对此持开放态度，但我现在并不过分关注这一点。
我遇到的问题是表需要获取某些组件信息。手头的问题是当我保存我的添加/编辑表单并需要处理自定义设置时。为了使未来尽可能灵活，我没有在数据库中表示所有这些可能的设置字段，而是将它们序列化为单个＆＃34; custom＆＃34;柱。 （通过自定义构造函数和getter读取这一切都很好。）我以前通过从League模型中的beforeSave函数加载组件，调用返回特定于日程安排的设置列表的函数，提取这些值和序列化它们。但随着3.0中组件访问的更改，我似乎无法再在新的beforeMarshal函数中创建组件。
我想控制器可以通过＆＃34;通过将其设置为属性来组合到表中，但这感觉就像一个主要的kludge，并且必须有更好的方法。看起来扩展表类似乎不是一个很好的解决方案，因为这会使关联变得非常复杂。我不认为custom types是解决方案，因为我也不知道他们如何访问组件。我只倾向于将控制器中的字段列表传递给模型，这更像是一个＆＃34;配置＆＃34;方法。说到配置，我想它可能只是进入中央配置数据存储，但我总觉得我只是在某个地方，你只是放置了＃34; small＆＃34;数据。我想知道是否有一个更好的设计模式，我可以让表继续自己处理这些实现细节，而无需控制器需要参与;如果在某些时候我决定从序列化方法更改为添加所有可能的列，那么将这些更改限制在表类中会很好。
哦，请记住，在视图和表格中都需要这个自定义设置列表，因此无论提出什么解决方案，理想情况下都会为他们提供访问它的方法，而不是要求重复代码。