2 回答

TA貢獻2011條經驗 獲得超2個贊
功能ControllerTrait::get($id)(獲取服務)以及ControllerTrait::getDoctrine()(獲取原則,這也是一項服務)都是通過訪問容器來完成的(如有疑問,請參閱參考資料),該容器在創建后AbstractController通過 via設置(this曾經這樣做是因為它實現了,它向 symfony 的依賴注入組件發出信號,它應該得到一個容器集,我不知道現在為什么/何時完成...... tbh)。AbstractController::setContainer($container) ContainerAwareInterface
而且,由于一個對象(在非靜態方法AbstractController中的這種情況下)只能被稱為(從外側)的對象已經從它的構造創建之后,并且由于setContainer是在對象上的非靜態方法中,AbstractController只能在構造函數完成后有一個容器,但在構造函數運行時沒有。
這就是為什么這兩個方法調用都不起作用的原因。
您的問題的解決方案非常簡單,因為絕對有效的是正確地依賴注入您需要的類:
use Symfony\Component\HttpFoundation\Session\SessionInterface;
use Doctrine\ORM\EntityManagerInterface;
class ProfileDao extends AbstractController {
private $id;
private $em;
function __construct(EntityManagerInterface $em, SessionInterface $session) {
$this->id = $session->get('id');
$this->em = $em;
}
}
一般來說,我避免使用容器,因為它絕對隱藏了控制器所具有的依賴項。我傾向于使用一些依賴項而不顯式注入它們(通常是 Twig 和一些 HttpKernel/HttpFoundation 的東西),因為它們在控制器中很常見/使用。

TA貢獻1765條經驗 獲得超5個贊
另一個想法,即使我更喜歡關于自動裝配的想法:您是否檢查過父構造函數是否有幫助?如果你擴展一個類(就像你正在做的那樣extends AbstractController
),你不應該忘記調用parent::__construct()
,也許是你自己construct
方法中的第一件事。這確保了父類正常工作所需的一切都被實例化。
- 2 回答
- 0 關注
- 143 瀏覽
添加回答
舉報