有些情况下，我需要在控制器和视图中运行相同的逻辑，我认为他们可能有共享代码，例如何时显示编辑链接和相同的逻辑应检查控制器中的编辑权限，其中我应该保留这样的代码，以便可以在控制器和视图中使用它，我可以为这个方法编写一个组件包装器和一个视图包装器，但核心逻辑应该是通用的。
一些提到的bootrap是一个地方，但放在那里我有所有蛋糕定义的参数或常量从该位置？或者有一个更好的地方
修改 我只提供了与身份验证相关的示例，但可能有更多情况，例如，基于数据库中设置的偏移时间（系统时间+关闭时间）显示数据/时间的视图助手，我也被迫在控制器中使用相同的代码（ajax）输出）。这意味着在通用代码中我们不仅拥有共享逻辑而且还拥有一些共享数据，因此只有会话类似乎提供共享数据！
答案 0 :(得分：3)
总的来说，我倾向于说你没有以正确的方式解决这个问题。如果你必须在控制器和视图中包含相同的逻辑，那么你很可能两次做同样的工作，这总是一个坏主意。干（不要重复自己）是你之前听过的一百万次。
但是，在你提到（身份验证）的情况下：这是在Controller中完成的，它依赖于Model层来查明用户是否有权查看/使用编辑链接。
根据控制器从Model层接收的数据，它应该执行以下操作之一：
对于第一种情况，一个可编辑且不可编辑的视图，可以选择使用相同的视图脚本，并使用a helper将会话信息传递给视图。有效地为视图提供检查用户会话的方法，检查相关用户是否具有查看编辑链接并呈现它们所需的权限...
另一个简单的修复方法是将视图的属性设置为true以获取可编辑状态，将false设置为不可编辑的控制器，并在视图中检查该bool标志。不需要额外的逻辑。
这里最重要的是你所追求的是对用户进行身份验证。当你到达视图时，路线是给定的，没有办法回来。如果您发现自己仍然需要验证用户的身份，那么您之前就犯了一个错误：控制器和模型层就是这种核心逻辑所在的位置。
一个视图不包含其自身的逻辑：一个循环或2，一些if-else的......仅此而已。
经验法则是：控制器做的第一件事是验证用户。身份验证本身是Model层的关注点：控制器中不应包含实际的核心/业务逻辑。根据调查结果，模型层返回（身份验证失败，或者用户有权执行X，但不能执行Y），控制器可以重定向，抛出错误或选择呈现特定视图。
只有在执行了所有这些操作之后才会引入视图。如果有用户正在播放，则视图可以假定此用户有效，并且具有查看其内容所需的权限。 该视图不会验证数据，也不会对用户进行身份验证 。
向用户验证特定于Cake的方式there's a core Authentication component，该方式似乎已被很好地记录。看看你是否不能使用它......
答案 1 :(得分：0)
您可以添加简单的函数来引导，但另一个选项是使用静态方法在app / Lib /中创建一个类。然后，您可以从任何控制器中包含库并使用定义的方法： -
App::uses('MyLibrary', 'Lib');
如果所有控制器都需要使用这些，只需在AppController中包含库。
对于您的观点，我会考虑定义一个可以应用MyLibrary中使用的方法的View Helper。