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