Во-первых, постарайтесь не слишком беспокоиться о производительности, пока не увидите где-то реальное узкое место. Верьте в множество систем кеширования. Говоря более цинично, Magento уже является чем-то вроде SQL-зверя, поэтому, если у вас настроен магазин, несколько дополнительных запросов не повредят.
Во-вторых, попадание в базу данных может даже не быть проблемой. Модель shipping/rate_request
не поддерживается базой данных. Если вы посмотрите на два раза, это используется в коде ядра
Mage_Shipping_Model_Shipping::collectRatesByAddress
Mage_Sales_Model_Quote_Address::requestShippingRates
вы видите, что модель shipping/rate_request
создается, а затем заполняется из уже загруженных полей. Кроме того, все модели, используемые в Mage_Shipping_Model_Carrier_Tablerate::collectRates
, ничего не загружают из базы данных, они просто выполняют вычисления.
Замечательно, что вы хотите создать что-то максимально эффективное на первом этапе, но в современной ОО-системе слишком много сложных взаимодействий, чтобы волшебным образом узнать наиболее эффективный способ что-то сделать. Делайте все, что вам нужно, чтобы получать необходимую информацию и настраивать производительность (при необходимости) во время технического обслуживания (или, если вам не повезло с техническим обслуживанием, когда кто-то из вашей организации ворчит о скорости где-то )
В-третьих, когда система не предоставляет доступ к тому, что вам нужно, для этого предназначена система переопределения классов. Что-то вроде
class Package_Module_Model_Carriertablerate extends
Mage_Shipping_Model_Carrier_Tablerate
{
public function getRate(Mage_Shipping_Model_Rate_Request $request)
{
$rate = parent::getRate($request);
Mage::register('package_module_carriertablerates', $rate);
return $rate;
}
}
...
//later, retrieve the rate
$rates = Mage::registry('package_module_carriertablerates');
Вы в основном вызываете тот же код, что и раньше, но храните результаты где-нибудь для последующего доступа. Примерно так безопасно, как может получить переопределение.