Каким был бы мой контроллер в этих сценариях в веб-приложении mvc?

Question

1) Какое место занимает домашняя страница вашего веб-сайта в разделе "контроллеры"?Я видел, что некоторые люди используют контроллер "страницы" для обработки статических страниц, таких как "о компании", "главная страница", "Контакты" и т.д., Но мне это не кажется хорошей идеей.Было бы лучшим вариантом создать отдельный контроллер только для вашей домашней страницы?В конце концов, возможно, потребуется доступ к нескольким моделям, и на самом деле это не очень хорошо сочетается с теорией одного контроллера на модель, которую используют некоторые люди.

2) Если вам нужна панель мониторинга для нескольких типов пользователей, будет ли это один контроллер панели мониторинга, который будет иметь код переключения в зависимости от того, какой пользователь, или у вас будет, скажем, действие панели мониторинга внутри каждого контроллера для каждого пользователя?Например, администратор / панель мониторинга, учетная запись / панель мониторинга и т.д.

3) Мне кажется, что использование всего простого примера CRUD работает как шарм при попытке объяснить контроллеры, но как только вы проходите мимо этих простых функций, это выходит из строя и может привести к тому, что ваши контроллеры станут громоздкими.Почему некоторые люди предпочитают создавать контроллер входа в систему, в то время как другие создают функцию входа в систему в пользовательском контроллере?Одна из причин, я думаю, заключается в том, что многие из нас имеют опыт работы со страницами, и трудно думать о контроллерах как об "объектах" или "существительных", потому что страницы не всегда работают таким образом.Например, с какой стати вам понадобилось бы создавать контроллер "страниц", который обрабатывал бы страницы, которые на самом деле не имеют ничего общего друг с другом, просто чтобы иметь "контейнер" для размещения действий.Просто мне это кажется неправильным.

4) Должны ли контроллеры иметь больше общего с вариантом использования, чем с "объектом", над которым можно выполнять действия?Для всех интенсивных целей вы могли бы создать пользовательский контроллер, который выполняет каждое действие во всем вашем приложении.Или вы могли бы создать контроллер для каждой "проблемной области", как любят говорить некоторые.Или вы могли бы создать по одному контроллеру для каждого представления, если хотите.Существует настолько большая свобода действий, что трудно найти последовательный метод для использования.

Вероятно, контроллеры не должны так сбивать с толку, но по какой-то причине они чертовски сбивают меня с толку.Будем очень признательны за любые полезные комментарии.

Answer 1

1) Я использую простой доморощенный набор классов для некоторых моих материалов MVC, и он связывает имена контроллеров с именами действий и представлений (это стиль фронт-контроллера, похожий на Zend).Для обычного веб-сайта предположим, что у него есть домашняя страница, политика конфиденциальности, страница контактов и страница о компании.На самом деле я не хочу создавать отдельные контроллеры для всех этих вещей, поэтому я вставлю их в свой IndexController, с такими именами функций , как actionIndex(), actionPrivacy(), actionContact(), и actionAbout().

Чтобы согласиться с этим, внутри моего каталога Views у меня есть каталог шаблонов, связанных с каждым действием.По умолчанию любое действие автоматически ищет связанный шаблон, хотя вы можете указать его при желании.Итак actionPrivacy() искал бы файл шаблона по адресу index/privacy.php, actionContact() стал бы искать index/contact.php, и т.д.

Конечно, это относится и к URL-адресам.Итак, URL-адрес, указанный на http://www.example.com/index/about побежал бы actionAbout(), который загрузил бы шаблон страницы About.Поскольку страница "о программе" представляет собой полностью статический контент, мой actionAbout() абсолютно ничего не делает, кроме как предоставляет общедоступное действие для просмотра и запуска Фронт-контроллером.

Итак, чтобы ответить на суть вашего вопроса, я помещаю несколько "страниц" в один контроллер, и это прекрасно работает для моих целей.Одна модель на контроллер - это теория, которой я не думаю, что стал бы придерживаться при работе с Web MVC, поскольку, похоже, она намного лучше подходит для приложения с состоянием.

2) Для этого у меня было бы несколько контроллеров.Следуя тем же методам, которые я использую выше, я бы имел /admin/dashboard и /account/dashboard как вы предлагаете, хотя нет никаких причин, по которым они не могли бы использовать одни и те же (или части одних и тех же) шаблонов.

Я полагаю, если бы у меня был миллион разных типов пользователей, я бы сделал вещи более универсальными и использовал только один контроллер, а также имел правило mod_rewrite для обработки загрузки.Вероятно, это будет зависеть от того, насколько функционально сложна панель мониторинга и как настроена учетная запись.

3) Я считаю, что функциональность CRUD сложно реализовать непосредственно в любом слое MVC и при этом она должна быть чистой, гибкой и эффективной.Мне нравится абстрагировать функциональность CRUD от уровня сервиса, к которому может обращаться любой объект, и иметь базовый класс объектов, из которого я могу расширять любые объекты, нуждающиеся в CRUD.

Я бы предложил использовать некоторые из существующих фреймворков PHP ORM для CRUD.Они могут избавить от многих хлопот, связанных с получением хорошей реализации.

Что касается контроллера входа в систему и пользовательского контроллера, я полагаю, это зависит от домена вашего приложения.С моим стилем программирования я бы склонен думать о "входе в систему" как о простой операции в пределах домена пользовательской модели, и, таким образом, у меня есть для нее одна операция внутри пользовательского контроллера.Чтобы быть более точным, я бы хотел, чтобы UserController создайте экземпляр модели пользователя и вызовите процедуру входа в систему для этой модели.Я не могу сказать вам, что это правильный путь, потому что я не мог бы с уверенностью сказать, каким должен быть правильный путь.Это вопрос контекста.

4) Вы правы насчет свободы действий.Вы могли бы легко создать контроллер, который обрабатывал бы все, что хотело делать ваше приложение / сайт.Тем не менее, я думаю, вы согласитесь, что это стало бы кошмаром для технического обслуживания.У меня до сих пор мурашки бегут по коже при воспоминании о моей последней работе в компании, занимающейся маркетинговыми исследованиями, где внутреннее PHP-приложение было создано зарубежной командой, причем, я могу только предположить, обучение было практически полным.Мы говорим о скриптах на 10 000 строк, которые обрабатывали весь сайт.Поддерживать это было невозможно.

Итак, я бы посоветовал вам разбить ваше приложение / сайт на бизнес-доменные области и создать контроллеры на их основе.Выясните основные концепции вашего приложения и действуйте исходя из этого.

Пример

Допустим, у меня был веб-сайт о ламантинах, потому что, очевидно, ламантинам нравится.Мне бы хотелось иметь несколько обычных страниц сайта (о компании, контакты и т.д.), управление учетными записями пользователей, форум, картинную галерею и, возможно, раздел материалов для исследовательских документов (с новейшими научными данными о ламантинах).Довольно просто, и многое из этого было бы статичным, но вы можете начать видеть разбивку.

IndexController - обрабатывает информацию о странице, политике конфиденциальности, общем статическом контенте.

UserController - управляет созданием учетной записи, входом / выходом из системы, настройками

PictureController - отображение изображений, обработка загрузок

ForumController - вероятно, не так уж много, я бы попытался интегрировать внешний форум, что означало бы, что мне здесь не понадобится много функциональности.

LibraryController - показывать списки последних новостей и исследований

HugAManateeController - виртуальные объятия ламантина в режиме реального времени по протоколу HTTP

Это, вероятно, дает вам, по крайней мере, базовое разделение.Если вы обнаружите, что контроллер становится чрезвычайно большим, вероятно, пришло время разбить бизнес-домен на отдельные контроллеры.

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

Web MVC может быть очень субъективным, поскольку он сильно отличается от модели MVC, где ваше приложение имеет состояние.Я стараюсь не использовать основные функциональные возможности контроллеров при работе с веб-приложениями.Мне нравится, когда они создают экземпляры нескольких объектов или моделей, запускают пару методов, основанных на выполняемом действии, и собирают некоторые данные представления, чтобы передать их в представление, как только это будет сделано.Чем проще, тем лучше, и я вкладываю основную бизнес-логику в модели, которые, как предполагается, отражают состояние приложения.

Надеюсь, это поможет.