MVC Каркасы.Когда вам нужен новый вид / модель?

Question

Я недавно начал использовать инфраструктуру CodeIgniter для своей разработки PHP.

Мне просто было любопытно, как исправить использование.

По существу, у меня следующая ситуация.

У меня есть контроллер, озаглавленный 'items'

Я хочу, чтобы, если пользователь заходит в items / index, он получает список категорий, если он переходит в items / category-name, он получает список элементов.

Для этого у меня есть один контроллер с оператором if / elseif, который загружает разные представления.Это правильный подход?

Если я нахожусь на странице наименований товаров / категорий, я загружаю представление, озаглавленное «список товаров», я передаю переменную, озаглавленную $ type, этому представлению.

В представлении он обнаруживает этот тип (снова с оператором if) и выводит заголовок категории (также переданный).Простой.

Кроме этого, у меня есть совершенно другой контроллер для списка недавно проданных товаров (не спрашивайте :)).Поскольку формат отображаемого списка по сути одинаков, я использую то же представление, но передаю другой тип $ var.Представление обнаруживает это, выводит различные «дополнительные» ссылки, изображения и т. Д. И, конечно, не выводит заголовок «категорий».

По сути, у меня есть 2 контроллера, использующих одно представление.С различными операторами if / elseif в контроллерах и в представлении для получения правильного вывода.

Это правильный подход?

Спасибо

Answer 1

Короче ...

нет единственного правильного или неправильного способа структурирования ваших контроллеров / представлений / моделей / библиотек / помощников.

Я тоже использую CI, и яОбнаружено, что к контроллерам с наименьшим количеством кода в каждом методе контроллера проще всего вернуться и отредактировать / сохранить / обновить / прочитать.Если в моих методах контроллера заложено слишком много логики, ясность и понимание теряются.Я пытаюсь поместить большую часть своей «логики» в библиотечные или вспомогательные методы, чтобы мои методы контроллера были простыми и легкими для чтения.

Мне нравится, когда контроллер принимает аргументы / данные, отправляет их моделям и /или библиотечные и вспомогательные методы, которые возвращают измененные или новые данные.Возвращенные данные могут быть отправлены другим методам перед окончательной отправкой в ​​представление.

Этот метод, как правило, направляет вас на поиск нескольких файлов при написании приложения или сайта, но обеспечивает четкое разделение представлений и логики.Надеемся, что это также поможет вам написать повторно используемый код, даже если его можно использовать только в одном приложении.

Что бы ни работало для вас и вашей команды, это нормально.

Answer 2

Для первой части вашего вопроса вы должны взглянуть на класс маршрутизации CI:

http://codeigniter.com/user_guide/general/routing.html

В этом подходе нет ничего принципиально неправильного, но вам действительно не нужны два контроллера. Предположительно, вы делаете это, чтобы ваши URI правильно отображались в браузере? Если так, допустим, у вас есть контроллеры, называемые items и solditems. Вы можете настроить маршрут так:

$ route ['solditems / (: any)'] = "items / solditems / $ 1";

Таким образом, когда кто-то вводит mysite.com/solditems/category, скрипт запускается на контроллере по адресу mysite.com/items/solditems/category.

.

Редактировать : Я должен также добавить кое-что о моделях, так как это было в вашем названии. По сути, вы хотите, чтобы контроллеры были слоем «доступа» для ваших приложений ... по сути, именно так, как у вас сейчас. Просмотр, очевидно, содержит визуальную презентацию вашего сайта. Модели обрабатывают все данные. Если вы хотите получить список всех продуктов, вам понадобится модель «продукты» и функция там, называемая «getProducts» или что-то в этом роде. Затем другой называется getProductById или что-то в этом роде. Если вы сообразительны, вы придумаете стандартный метод форматирования данных, так что вы всегда будете знать, чего ожидать от вызовов данных, и, таким образом, сможете передавать возвращаемые значения непосредственно из вашей модели в представление от до ваш контроллер. Поэтому, если вы хотите получить все проданные товары, у вас может быть контроллер, который обрабатывает запрос и выполняет вызов модели, модель выполнит запрос к базе данных и доставит данные обратно в контроллер любым удобным для вас способом, и Ваш контроллер будет полностью независим от того, что возвращается, но просто передает эту переменную в представление для обработки визуально. Вы также можете обрабатывать некоторую логику представления в вашем контроллере, если у вас есть большое количество представлений (например, если у вас есть одно представление, которое является «элементом списка» для одного из ваших проданных предметов ... вы можете использовать свой контроллер перебрать переменную, возвращаемую из модели, передавая их один за другим в представление «элемент списка», конкатенировать эту строку (см .: необязательный третий параметр для $ this-> load-> view ()), а затем вставить эту строку в виде списка.

Вы можете проявить себя настолько креативно, насколько захотите, если только вы помните, что смысл всего этого заключается в том, чтобы логически отделить уровень доступа от уровня представления от уровня данных. Помимо этого абстрактного разделения, нет «лучших практик», только то, что лучше для вас.

Answer 3

Как уже говорили другие, не существует действительно четкого «правильного» пути.Все, что работает для вас.Для меня, как правило, я использую около одного представления на действие.(Я использую больше, если это действие обрабатывает форму или что-то в этом роде.)

Например, у меня может быть:

'items/view/7'

, который имеет вид для определенного продукта

'category/view/3'

, которая имеет представление для категории

По мере использования codeigniter вы обнаружите, что вы найдете более организованные (и, следовательно, более «обслуживаемые» для вас).А с некоторыми небольшими приложениями я даже позже реорганизовал все (я имею в виду буквально, переставил классы и функции и папки, содержащие представления), чтобы сделать его более логичным.

Я не вижу ничего «неправильного»"с тем, что вы делаете.Хотя то, как это звучит в последней части вашего поста, где вы используете одно и то же представление и просто имеете переменные, которые обрабатывают то, что собирается делать представление, я бы, вероятно, избежал этого (хотя это зависит и от других вещей).Я, вероятно, просто имею представление о «недавно проданных продуктах», которое не зависит от представления «категории».Очень логично, что представление делает обычно хорошей идеей.