谁负责购物车会话管理？答案

【问题标题】：who is responsible for cart session management?谁负责购物车会话管理？
【发布时间】：2016-01-16 19:38:16
【问题描述】：

我为最近做的一个网站设计了一个购物车。为了我的坚持，我选择了会话。目前，购物车负责自己的会话管理。当Cart 被实例化时，constructor 使用Session 外观从会话中恢复购物车。当Cart 被销毁时，destructor 将购物车的当前状态保存到会话中，再次使用外观。我知道这不好，需要重构。

我看到了 2 条可能的会话管理路线，所以我的问题是，管理会话是谁的责任？控制器是否应该负责在会话中保存和恢复购物车？或者我是否将会话层注入到购物车中，并且购物车仍然在内部处理它？

我会说我使用 php __destruct() 得到的结果好坏参半，因为它可以在关机序列期间以任何顺序调用。我想我想放弃使用它，因为它的行为不可预测（除非有人说服我不这样做）。

购物车处理自己的会话存储的一个好处是，我只需在 1 位置处理保存和恢复。如果我走控制器路线，我想我将需要 restore() 和 save() 它用于每个需要它的控制器方法。如果清理购物车的依赖项，我不反对，但显然我们总是喜欢少写代码。

我知道这个问题有点开放式，可能会征求基于意见的答案，所以请提供具体示例，说明您尝试过的方法是否有效，以及它们的优缺点。

谢谢！

【问题讨论】：

这里没有真正的要求，只要会话处于活动状态，购物车就处于活动状态。为什么要问？
大概 30 分钟，无论我的 php 配置文件中的默认值是什么。
没关系。通过使用依赖注入，选择另一个实现很简单
不，它已经消失了。虽然这是一个有效的选择，但这是一个完全不同的讨论。我选择了这个项目的会议，因为它符合业务需求。我的问题是关于会话管理的责任。

标签： php laravel session

【解决方案1】：

控制器中没有会话处理。那是为了授权和整合。

会话应由会话处理程序处理。使用依赖注入，您可以在构造函数中注入处理程序。这对可维护性、可扩展性和可测试性很有好处。

【讨论】：

我同意。我注入了一个会话处理程序。但是仍然需要有人告诉会话处理程序设置或获取变量。那应该是购物车还是控制器？
使用依赖注入，您可以使用该对象的方法。在这种情况下，控制器获取输入并将其传递给其 DI 对象的方法。
最好为您的会话处理程序实现一个接口，例如 CartStorageHandlerInterface。构造函数应该期望一个实现此接口的对象。因此，您可以轻松地进行其他实现，例如SessionStorageHandler、DatabaseStorageHandler、FileStorageHandler等都实现了CartStorageHandlerInterface。非常糟糕！ ;-)
那么您是否建议将会话处理程序注入Cart，然后Cart 在内部使用注入的会话处理程序进行恢复和保存？
您可以在控制器的构造函数中注入会话处理程序。该对象包含处理会话的逻辑。控制器可以提供对此的输入，但控制器对“如何处理会话”一无所知。