如何地獄我抓住一個配置項從application.config.php
模型裏面?
你不應該這樣做內,做 '外'。
註冊您的模型類作爲module.config.php
服務。
'service_manager' => [
'factories' => [
'Email\Model\EmailModel' => 'Email\Model\EmailModelFactory',
]
],
然後創建工廠Email\Model\EmailModelFactory
,這使用服務管理器來獲取「電子郵件」配置密鑰,並將其注入到模型的構造。
namespace Email\Model;
use Email\Model\EmailModel;
use Zend\ServiceManager\ServiceLocatorInterface;
use Zend\ServiceManager\FactoryInterface;
class EmailModelFactory implements FactoryInterface
{
public function createService(ServiceLocatorInterface $serviceLocator)
{
return new EmailModel($this->getEmailOptions($serviceLocator));
}
// Return the email options
public function getEmailOptions(ServiceLocatorInterface $serviceLocator)
{
$options = $serviceLocator->get('config');
return $options['email'];
}
}
你現在應該有更多的問題是你的模型類的呼叫將必須按順序使用$serviceManager->get('Email\Model\EmailModel')
(而不是new \Email\Model\EmailModel
)對於要注入的配置。即使沒有看到你的遺留應用程序,我的猜測是這將是困難的。
模型不應該是負責發送電子郵件;您可以將其替換爲服務類,例如'EmailService'並重覆上面的注入示例,僅供此類使用。
EmailService::send(EmailModel $email, array $options);
這將讓你的模型獨立,就沒有必要更換調用new Model
等
謝謝你的回答。做一些應該很簡單的事情似乎是一個漫長的過程。我並不是全力支持Laravel,但像拉入全局配置應該很容易。 – EquinoxMatt
這是一個*服務定位器*,地獄它甚至有服務定位器的名稱。這是**反模式**,直接反對依賴注入。它使你的對象API成爲騙子。這不是任何*面嚮對象語言的前進方向,不用介意PHP。 – Jimbo
@Jimbo請具體向我解釋一下上面那個讓你覺得這個的部分?通過簡單地說明在DI容器上使用服務定位器,「反模式」僅僅是錯誤的,並沒有增加任何價值。我猜你已經讀過關於服務定位器被濫用的信息;也許將它們與正在創建的服務耦合起來?如果是這樣,我會建議閱讀ZF2的基礎知識,特別是[服務工廠](http://framework.zend.com/manual/current/en/in-depth-guide/services-and-servicemanager.html#writing-a -factory-class),因爲在上面的代碼中情況並非如此。 – AlexP