Можете ли вы получить доступ к модели изнутри другой модели в CodeIgniter?
Я пишу веб-приложение с использованием CodeIgniter, которое требует аутентификации. Я создал модель, которая обрабатывает всю мою аутентификацию. Однако я не могу найти способ получить доступ к этой модели аутентификации из другой модели. Есть ли способ получить доступ к модели из другого режима или лучший способ обработки аутентификации внутри CodeIgniter?
Ответы 4
В общем, вы не хотите создавать объекты внутри объекта. Это плохая привычка, вместо этого писать четкий API и внедрять модель в свою модель.
<?php
// in your controller
$model1 = new Model1();
$model2 = new Model2();
$model2->setWhatever($model1);
?>
Да, лучше «внедрить» зависимость, чем инициализировать Model2 внутри Model1.
Это звучит не очень хорошо с точки зрения СУХОЙ. Что, если у меня есть функция, которая изменяет аспект одной модели и запускает действие для другой модели?
Я полностью согласен - model2 не должен переходить в model1 с самого начала. Но если это необходимо, это лучшее, что вы можете сделать.
Это не очень хорошая практика. Если вам нужно использовать модель внутри модели, рассмотрите возможность получения экземпляра CI.
Что не является хорошей практикой? Внедрение зависимостей является - хорошая практика!
@Till Ты скучаешь по лесу за деревьями. Совершенно нормально создать модель внутри другой модели - если они будут тесно связаны. Нет необходимости вводить все зависимости и полностью отделять каждый класс от другого. На самом деле сделать это чертовски невозможно. Что вам нужно сделать, так это найти линии разлома в вашей системе, места, где может быть разумно достигнута слабая связь. Изолируйте эти модули и системы друг от друга и используйте там внедрение зависимостей. Не все нужно тестировать изолированно.
@DanielBingham Я никогда не говорил, что не бывает крайних случаев. Могут быть ситуации, когда то, что вы сказали, необходимо сделать, но, честно говоря, я не могу ни о чем думать. :) DI - определенно хорошая практика. Вы также комментируете ответ, который я дал 3 года назад.
@till Ему может быть три года, но люди все еще находят его (я нашел). Так что это все еще открыто для обсуждения;) Я в основном возражаю против вашего первого утверждения: «В общем, вы не хотите создавать объекты внутри объекта». Это неправда. Период. Большинство шаблонов объектно-ориентированного проектирования требуют создания объектов внутри объектов. И вы не можете вводить их все. Попробуйте использовать заводской шаблон, вводя все созданное. В этом заключается вся суть шаблона. Теперь более спорным является вопрос о том, является ли хорошей практикой создание модели CI внутри модели CI ...
@DanielBingham Для проверки кода я возражаю против введения зависимостей в объект, которые нелегко заменить. Это все, что я говорю - и поэтому я все еще придерживаюсь своей исходной точки зрения, что вы должны стремиться к DI.
@Till Зависимость между модули или составные части, не обязательно между объектами. Требовать, чтобы все объекты, используемые любым другим объектом, были внедрены, просто глупо. В большинстве случаев вам не нужно тестировать объекты изолированно.
Я думал, что вся идея объектно-ориентированного программирования заключается в возможности создавать иерархии объектов так, как вы хотите.
Почему не рекомендуется загружать объекты внутри объектов? Это может быть очень хорошей практикой. Все зависит от вашего дизайна и целей. Фактически, большинство переменных-членов будут объектами. Большинство локальных переменных будут объектами.
Я не хочу больше спорить с этим, потому что каждые пару месяцев кто-то хочет выразить собственное мнение. Существует вещь, называемая внедрением зависимостей (DI), которая позволяет вам и мне обмениваться зависимостями объекта - во всяком случае, это преимущество для «поддерживаемого кода» (качество кода) и LBNL для тестирования. Утверждать, что вам не нужно тестировать объекты изолированно, - это нормально, но тогда вы больше не модульное тестирование. И хотя вы стремитесь протестировать бизнес-логику, вы в конечном итоге тестируете всю структуру и базу данных под ней. Это не облегчает поиск ошибки в вашем коде.
Не обрабатывайте аутентификацию в своей модели. Используйте модели только для взаимодействия с вашей базой данных, ldap или чем-то еще.
Я создал библиотеку Auth, которую использую для управления аутентификацией и авторизацией. Вы можете получить доступ к такой библиотеке со своих контроллеров.
Я всегда помещаю свои реализации oauth в модель, мне не нравится забивать свои контроллеры кодом аутентификации
Я создаю MY_controller и делаю там все oauth.
Кажется, вы можете загружать модели внутри моделей, хотя вам, вероятно, следует решить это по-другому. См. Обсуждение в Форумы CodeIgniter.
class SomeModel extends Model
{
function doSomething($foo)
{
$CI =& get_instance();
$CI->load->model('SomeOtherModel','NiceName',true);
// use $CI instead of $this to query the other models
$CI->NiceName->doSomethingElse();
}
}
Кроме того, я не понимаю, что говорит Тилль о том, что вы не должны создавать объекты внутри объектов. Конечно, стоит! Отправка объектов в качестве аргументов мне кажется менее понятной.
Жалоба заключается в том, что это без необходимости создает более сильную зависимость между двумя моделями. Например, когда вы тестируете, приятно иметь возможность предоставить SomeModel фиктивную версию SomeOtherModel; вы не можете этого сделать, если первое загружает второе напрямую. Или вы изменяете код позже, чтобы использовать другую модель с тем же интерфейсом, например, когда вы реорганизуете существующий код для использования системы плагинов.
У Google есть среда внедрения зависимостей с открытым исходным кодом. Это для Java, но в нем объясняются плюсы и некоторые минусы внедрения зависимостей. code.google.com/p/google-guice
@Rob Howard Есть такая вещь, как зайти слишком далеко с внедрением зависимостей. Нет необходимости внедрять каждый отдельный объект, который вы используете, поскольку не каждый отдельный объект, который вы используете, нужно тестировать изолированно. Скорее вы хотите протестировать системы и модули, которые работают вместе как единое целое, и их нужно изолировать друг от друга и внедрить.
Я не могу поверить, что этот ответ набрал 15 голосов. Причина, по которой он стоит, заставляет меня съеживаться, Это антипаттерн антипаттернов (и нет, он не делает его хорошим двойным отрицанием)
Загрузка модели в модель теперь возможна с новым CodeIgniter.
Это хорошая практика? Потому что пользователь Model2 должен знать, что он зависит от Model1. Какая хорошая практика?